Re: Questions about powerpc __tls_get_addr optimization

[Rich Felker <dalias at libc dot org>]

On Sat, Oct 13, 2018 at 10:54:23AM +1030, Alan Modra wrote:
> On Fri, Oct 12, 2018 at 10:08:30AM -0400, Rich Felker wrote:
> > 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.
> 
> Yes, that is possible but unlikely.  Another concern if you are
> thinking about adapting the PowerPC scheme to other targets, without
> some tag from the linker, is that dynamic relocations are not needed
> in the executable on the tls_index words for a General Dynamic TLS
> access to a locally defined TLS variable.  Of course, such access
> sequences are generally edited to a Local Exec TLS sequence if the
> linker implements TLS code editing.  So if the linker does not
> implement TLS editing (or the editing is disabled), and the linker
> happens to emit a dynamic DTPMOD relocation unnecessarily but not a
> dynamic DTPREL relocation, then you have your scenario where it's
> wrong for the DTPMOD to modify the second tls_index word.
> 
> The presence of the PPC64_OPT_TLS dynamic tag bit asserts that the
> linker hasn't introduced such silliness with dynamic relocations.

OK, that's very helpful. I think my variant solves this problem, by
not trying to mix data from the two slots. slot[0] just stores
tp-dtv[modid] so that when slot[0]<0, tp-slot[0]+slot[1] yields the
same thing as dtv[modid]+slot[1]. (And on targets where tls is below
tp, dtv[modid]-tp is used instead, with tp+slot[0]+slot[1] being the
result.) The cost seems to be one add, but the operand is already in a
register from branching on it.

Rich