This is the mail archive of the
mailing list for the glibc project.
Re: POWER PC-relative addressing and new text relocations
* 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:
>> >> 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?
> Yes. I should have mentioned that too.
Yuck. Is this *really* necessary?
>> 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?
> I thought you can't dlopen libraries with static TLS, except when the
> amount of TLS storage needed fits within a certain limit, but it's a
> while since I looked at glibc code in this area so things may have
That's right, we have this restriction with static TLS. This is not
specific to PCREL or -ftls-model=local-exec.