[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 25 May 2019 12:51:33 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: musl can't handle gold's STB_LOCAL TLS symbols
On Sat, May 25, 2019 at 11:18:16AM +0200, Szabolcs Nagy wrote:
> * Rich Felker <dalias@...c.org> [2019-05-23 21:12:04 -0400]:
> > On Thu, May 23, 2019 at 05:47:13PM -0700, Ryan Prichard wrote:
> > > The test program works with ld.bfd, because ld.bfd converts the DTPMOD
> > > relocation to 0 and omits the DTPOFF relocation. There was a somewhat
> > > similar issue with gold+musl involving a DTPMOD relocation to a
> > > local section symbol, https://sourceware.org/bugzilla/show_bug.cgi?id=17699.
> > > That issue prompted a thread on the generic-abi group,
> > > https://groups.google.com/d/topic/generic-abi/dJ4_Y78aQ2M/discussion.
> > >
> > > I'm wondering if this problem is a bug in musl or gold. I also wonder if
> >
> > I would consider this a bug in gold. There is no reason to leave local
> > symbols unresolved until runtime; resolving them is ld's whole job.
> >
> > > DTPOFF can reference a TLS section, even though the value of a TLS section
> > > symbol isn't suitable for DTPOFF unless it's first adjusted by the
> > > segment's p_vaddr.
> >
> > I don't see a good reason for it to reference a section either. It
> > should just have a 0 symbol reference, and store the ld-determined
> > offset to the object in the addend. Any kind of symbolic reference
> > here is just going to be a waste of time doing a lookup at runtime.
>
> the sysv elf spec allows leaving STB_LOCAL symbols
> in the dynamic symbol table if they were hidden [1].
> it does not say if symbolic dynamic relocs may refer
> to them, though.
I don't think there's any reasonable way a reference to the symbol
from a relocation can distinguish between one that needs to use the
local definition and one that needs to follow normal global symbol
resolution, is there? Or can it just skip the lookup entirely and use
the reference as the definition in this case?? If that's possible it
might be trivial and non-controversial to support.
> i think it should not be too hard to adjust
> do_relocs to handle this, not sure about do_dlsym.
> current dlsym does not seem to check OK_BIND
> so a local sym may preempt a global one.
This is a bug we need to fix. It was probably fixed by your old patch
to unify symbol lookup paths, but that bitrotted before it ever got
applied.
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.
