Re: POWER PC-relative addressing and new text relocations

[Alan Modra <amodra at gmail dot com>]

On Mon, Sep 23, 2019 at 10:37:29AM +0200, Florian Weimer wrote:
> * Alan Modra:
> 
> > On Mon, Sep 23, 2019 at 09:42:52AM +0200, Florian Weimer wrote:
> >> At Cauldron, the question came up whether the dynamic loader needs to
> >> be taught about the new relocations for PC-relative addressing.
> >> 
> >> I think they would only matter if we supported PC-relative addressing
> >> *and* text relocations.  Is that really necessary?
> >> 
> >> These text relocations would not work reliably anyway because the
> >> maximum displacement is not large enough.  For example, with the
> >> current process layout, it's impossible to reach shared objects from
> >> the main program and vice versa.  And some systems might want to add
> >> additional randomization, so that shared objects are not mapped closed
> >> together anymore.
> >
> > We've been discussing this inside IBM too.  The conclusion is that
> > only one of the new relocs makes any possible sense as a dynamic
> > reloc, R_PPC64_TPREL34, and that one only if you allow
> > -ftls-model=local-exec when building shared libraries and accept that
> > DF_STATIC_TLS shared libraries that can't be dlopen'd are OK.
> 
> Is this still a text relocation?

Yes.  I should have mentioned that too.

>  The displacement relative to the
> thread pointer is (usually) small, so I can see how this could work
> reliable.
> 
> What's the restriction on dlopen?  Wouldn't it be the same as regular
> initial-exec TLS memory, which also uses static TLS, but without a
> text relocation and an additional indirection to load the TLS offset
> from a place where a regular relocation has put it?

I thought you can't dlopen libraries with static TLS, except when the
amount of TLS storage needed fits within a certain limit, but it's a
while since I looked at glibc code in this area so things may have
changed.

-- 
Alan Modra
Australia Development Lab, IBM