* 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 > changed. That's right, we have this restriction with static TLS. This is not specific to PCREL or -ftls-model=local-exec.
