This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: POWER PC-relative addressing and new text relocations
- From: Alan Modra <amodra at gmail dot com>
- To: Florian Weimer <fw at deneb dot enyo dot de>
- Cc: binutils at sourceware dot org, libc-alpha at sourceware dot org, gcc at gcc dot gnu dot org, Tulio Magno Quites Machado Filho <tulioqm at br dot ibm dot com>
- Date: Mon, 23 Sep 2019 19:23:05 +0930
- Subject: Re: POWER PC-relative addressing and new text relocations
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