This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: POWER PC-relative addressing and new text relocations


* 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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]