This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] PPC64 tls fixes
On Wed, Mar 05, 2003 at 04:33:41PM -0800, Roland McGrath wrote:
> > Yes. The thing that makes this question a little curly is that
> > TPREL16 relocs will only be dynamic if a shared lib is compiled
> > using the LE model. Doing so is every bit as silly as using non-PIC
> > shared libs, perhaps even more silly, so it may be better for the
> > linker just to bomb on finding these relocs.
> These relocs will only be produced for non-PIC code, period. Right? In
No. TPREL16 for LE model tls vars, regardless of PIC/non-PIC.
> PIC code, the only TPREL relocs are in the TOC and that's only TPREL64.
> It's IE-model non-PIC code that will be the issue. This is arguably no
> more dubious than non-PIC code in a shared library is to begin with.
TPREL64 in the TOC/GOT for IE model, again PIC/non-PIC isn't relevant.
Strictly speaking, I suppose you could generate them via assembly
in any section.
> > I added support in the linker because it was easy to do, and it's
> > generally a good idea to be permissive in what the linker accepts. On
> > the other hand, we don't want to bloat code in ld.so.
> What we want is a clear spec on what is kosher and to support everything
> that is valid under the ABI as specified. If non-PIC code is not kosher,
> then fine, we won't support it. But that's not what you said before.
> ld.so must support everything that is specified to be valid.
If LE in a shared lib makes any sort of sense then they're valid.
I'm happy to listen to opinions from TLS experts on this point. :)
To the best of my knowledge, this is an exhaustive list of ppc64 reloc
types that may be emitted in dynamic relocations.
Hmm, which doesn't match dl-machine.h support.. Note in particular
that REL24 is never dynamic on ppc64.
IBM OzLabs - Linux Technology Centre