This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: [PATCH] PPC64 tls fixes
- From: Roland McGrath <roland at redhat dot com>
- To: Alan Modra <amodra at bigpond dot net dot au>
- Cc: sjmunroe at us dot ibm dot com, libc-alpha at sources dot redhat dot com
- Date: Wed, 5 Mar 2003 16:33:41 -0800
- Subject: Re: [PATCH] PPC64 tls fixes
> 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
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.
> 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.