Re: POWER PC-relative addressing and new text relocations

[Florian Weimer <fw at deneb dot enyo dot de>]

* Alan Modra:

> 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.

Yuck.  Is this *really* necessary?

>> 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.

That's right, we have this restriction with static TLS.  This is not
specific to PCREL or -ftls-model=local-exec.