POWER PC-relative addressing and new text relocations

[Florian Weimer]

* Alan Modra:

> On Mon, Sep 23, 2019 at 11:14:12AM +0200, Florian Weimer wrote:
>> * 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:
>> >> > 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?
>
> The idea was to allow lusers to do the same as they can on other
> architectures, to minimise the number of bug reports saying "but I can
> do this on x86".
>
> Hmm, I just checked.
> $ gcc -shared -fPIC -ftls-model=local-exec -o thread.so ~/src/tmp/thread.c
> /usr/bin/ld: /tmp/ccoXMrxD.o: relocation R_X86_64_TPOFF32 against
> symbol `p' can not be used when making a shared object; recompile with
> -fPIC

It works with -m32.  In theory, we still have DT_TEXTREL support for
x86-64 in the loader, but I think BFD ld at least does not really
support it.  Since x86-64 only has 32-bit displacements, text
relocations suffer from similar limitations as they would on POWER, so
this looks to me mostly like a historical accident (like the existing
text relocations that are recognized by the loader on POWER ELFv2).

Going forward, I'll assume that we won't need any loader changes on
POWER, and will not promote text relocations, either.  It's nice that
there isn't something left to do for us for once.