This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]