This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: POWER PC-relative addressing and new text relocations
- From: Florian Weimer <fw at deneb dot enyo dot de>
- To: Alan Modra <amodra at gmail dot com>
- Cc: binutils at sourceware dot org, libc-alpha at sourceware dot org, gcc at gcc dot gnu dot org
- Date: Mon, 23 Sep 2019 10:37:29 +0200
- Subject: Re: POWER PC-relative addressing and new text relocations
- References: <87o8zbcvb7.fsf@mid.deneb.enyo.de> <20190923083122.GC3685@bubble.grove.modra.org>
* Alan Modra:
> On Mon, Sep 23, 2019 at 09:42:52AM +0200, Florian Weimer wrote:
>> At Cauldron, the question came up whether the dynamic loader needs to
>> be taught about the new relocations for PC-relative addressing.
>>
>> I think they would only matter if we supported PC-relative addressing
>> *and* text relocations. Is that really necessary?
>>
>> These text relocations would not work reliably anyway because the
>> maximum displacement is not large enough. For example, with the
>> current process layout, it's impossible to reach shared objects from
>> the main program and vice versa. And some systems might want to add
>> additional randomization, so that shared objects are not mapped closed
>> together anymore.
>
> 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? The displacement relative to the
thread pointer is (usually) small, so I can see how this could work
reliable.
What's the restriction on dlopen? Wouldn't it be the same as regular
initial-exec TLS memory, which also uses static TLS, but without a
text relocation and an additional indirection to load the TLS offset
from a place where a regular relocation has put it?