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 So I'm not fussed if we drop the idea of supporting R_PPC64_TPREL34 as a dynamic reloc. -- Alan Modra Australia Development Lab, IBM