[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20191022025942.GK16318@brightrain.aerifal.cx>
Date: Mon, 21 Oct 2019 22:59:42 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] remove remaining traces of __tls_get_new
On Mon, Oct 21, 2019 at 05:50:30PM -0700, Fangrui Song wrote:
> On 2019-09-29, Rich Felker wrote:
> >On Sun, Sep 29, 2019 at 03:05:27PM +0200, Szabolcs Nagy wrote:
> >>reported on irc by malc_
> >
> >>>From 4a7090ab76d81b59f57a83bce9d22582e35a8b2b Mon Sep 17 00:00:00 2001
> >>From: Szabolcs Nagy <nsz@...t70.net>
> >>Date: Sun, 29 Sep 2019 12:25:39 +0000
> >>Subject: [PATCH] remove remaining traces of __tls_get_new
> >>
> >>Some declarations of __tls_get_new were left in the code, even
> >>though the definition got removed in
> >>
> >> commit 9d44b6460ab603487dab4d916342d9ba4467e6b9
> >> install dynamic tls synchronously at dlopen, streamline access
> >>
> >>this can make the build fail with
> >>
> >> ld: lib/libc.so: hidden symbol `__tls_get_new' isn't defined
> >>
> >>when libc.so is linked without --gc-sections, because a .hidden
> >>declaration in asm code creates a reference even if the symbol
> >>is not actually used.
> >
> >This is definitely a tooling bug. There is no reference to the symbol,
> >only declarations of it. I think it's a good idea to cleanup the
> >spurious mentions of it anyway, though.
>
> I think it is hard to simply state that this is a tooling bug.
> For the visibility attribute of a symbol, it may still be emitted into
> the symbol table even if it is unused. For example:
>
> ..protected foo => STV_PROTECTED foo
> ..hidden foo => STV_HIDDEN foo
>
> A relocation referencing a symbol may be dropped due to --gc-sections.
> Shall we consider the symbol unused if all relocations to it are
> dropped?
I don't think --gc-sections is relevant except that it happened to
make the problem go away. This isn't about ld spuriously thinking
there's a reference to a symbol after --gc-sections dropped the
sections containing relocations referencing it.
Rather, it looks like a bug in --no-undefined, which as documented
should only produce an error when there's a *reference* (i.e. an
outstanding relocation using) the undefined symbol, instead erroring
out just because an undefined symbol appears in the linker's working
symbol table for the purpose of tracking its declared visibility.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
