This is the mail archive of the
mailing list for the glibc project.
Re: Questions about powerpc __tls_get_addr optimization
On Fri, Oct 12, 2018 at 10:20:43PM +1030, Alan Modra wrote:
> On Thu, Oct 11, 2018 at 10:00:46PM -0400, Rich Felker wrote:
> > On Fri, Oct 12, 2018 at 11:38:14AM +1030, Alan Modra wrote:
> > > On Thu, Oct 11, 2018 at 05:26:54PM -0400, Rich Felker wrote:
> > > > My concern with doing this would be that there's no relocation on the
> > > > second (offset) slot when the local-dynamic model is used, and I
> > > > thought ld would be doing something special to account for this when
> > > > the optimization is used, but apparently your code in the glibc
> > > > dynamic linker just ignores this and fills in both slots when
> > > > processing the R_PPC64_DTPMOD64 relocation.
> > >
> > > Right, the slots are filled in for local dynamic at that point.
> > Do you think it's safe to overwrite these in the dynamic linker?
> The implementation we have currently for powerpc is safe, because the
> reloc processing is all done at startup. If you're talking about
> modifying the tls_index pair at run time by __tls_get_addr, then that
> should be safe too. You'd be modifying thread-local data.
I meant at startup; rather I was asking if there's a possibility that
the second slot contains something other than a 0 (indicating
__tls_get_addr should return a pointer 0x8000 into the TLS space of
the module identified by the modid). For example, it seems conceivable
that asm that wanted a pointer to the start of the TLS space could put
-0x8000 in the offset position so that __tls_get_addr would return
that, and if the dynamic linker clobbered it when setting up the
(0,tprel) form, that would get lost.