mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: [PATCH] remove remaining traces of __tls_get_new
Date: Mon, 21 Oct 2019 22:59:42 -0400	[thread overview]
Message-ID: <20191022025942.GK16318@brightrain.aerifal.cx> (raw)
In-Reply-To: <20191022005030.vcmt2smjyqhcjkfw@gmail.com>

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@port70.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


      reply	other threads:[~2019-10-22  2:59 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-29 13:05 Szabolcs Nagy
2019-09-29 20:56 ` Rich Felker
2019-10-22  0:50   ` Fangrui Song
2019-10-22  2:59     ` Rich Felker [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191022025942.GK16318@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).