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