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 > 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? 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 changed. -- Alan Modra Australia Development Lab, IBM
