This is the mail archive of the
mailing list for the glibc project.
Re: POWER PC-relative addressing and new text relocations
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.
> The displacement relative to the
> thread pointer is (usually) small, so I can see how this could work
> 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
Australia Development Lab, IBM