* POWER PC-relative addressing and new text relocations @ 2019-09-23 7:43 Florian Weimer 2019-09-23 8:31 ` Alan Modra 0 siblings, 1 reply; 7+ messages in thread From: Florian Weimer @ 2019-09-23 7:43 UTC (permalink / raw) To: binutils, libc-alpha, gcc 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: POWER PC-relative addressing and new text relocations 2019-09-23 7:43 POWER PC-relative addressing and new text relocations Florian Weimer @ 2019-09-23 8:31 ` Alan Modra 2019-09-23 8:37 ` Florian Weimer 0 siblings, 1 reply; 7+ messages in thread From: Alan Modra @ 2019-09-23 8:31 UTC (permalink / raw) To: Florian Weimer; +Cc: binutils, libc-alpha, gcc 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. See https://sourceware.org/ml/binutils/2019-09/msg00164.html, which doesn't allow even R_PPC64_TPREL34. I haven't put this patch on the binutils 2.33 branch. -- Alan Modra Australia Development Lab, IBM ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: POWER PC-relative addressing and new text relocations 2019-09-23 8:31 ` Alan Modra @ 2019-09-23 8:37 ` Florian Weimer 2019-09-23 9:06 ` Alan Modra 0 siblings, 1 reply; 7+ messages in thread From: Florian Weimer @ 2019-09-23 8:37 UTC (permalink / raw) To: Alan Modra; +Cc: binutils, libc-alpha, gcc * 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? ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: POWER PC-relative addressing and new text relocations 2019-09-23 8:37 ` Florian Weimer @ 2019-09-23 9:06 ` Alan Modra 2019-09-23 9:14 ` Florian Weimer 0 siblings, 1 reply; 7+ messages in thread From: Alan Modra @ 2019-09-23 9:06 UTC (permalink / raw) To: Florian Weimer; +Cc: binutils, libc-alpha, gcc 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: POWER PC-relative addressing and new text relocations 2019-09-23 9:06 ` Alan Modra @ 2019-09-23 9:14 ` Florian Weimer 2019-09-23 9:53 ` Alan Modra 0 siblings, 1 reply; 7+ messages in thread From: Florian Weimer @ 2019-09-23 9:14 UTC (permalink / raw) To: Alan Modra; +Cc: binutils, libc-alpha, gcc * 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: POWER PC-relative addressing and new text relocations 2019-09-23 9:14 ` Florian Weimer @ 2019-09-23 9:53 ` Alan Modra 2019-09-23 10:01 ` Florian Weimer 0 siblings, 1 reply; 7+ messages in thread From: Alan Modra @ 2019-09-23 9:53 UTC (permalink / raw) To: Florian Weimer Cc: binutils, libc-alpha, gcc, Tulio Magno Quites Machado Filho On Mon, Sep 23, 2019 at 11:14:12AM +0200, Florian Weimer wrote: > * 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: > >> > 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? The idea was to allow lusers to do the same as they can on other architectures, to minimise the number of bug reports saying "but I can do this on x86". Hmm, I just checked. $ gcc -shared -fPIC -ftls-model=local-exec -o thread.so ~/src/tmp/thread.c /usr/bin/ld: /tmp/ccoXMrxD.o: relocation R_X86_64_TPOFF32 against symbol `p' can not be used when making a shared object; recompile with -fPIC So I'm not fussed if we drop the idea of supporting R_PPC64_TPREL34 as a dynamic reloc. -- Alan Modra Australia Development Lab, IBM ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: POWER PC-relative addressing and new text relocations 2019-09-23 9:53 ` Alan Modra @ 2019-09-23 10:01 ` Florian Weimer 0 siblings, 0 replies; 7+ messages in thread From: Florian Weimer @ 2019-09-23 10:01 UTC (permalink / raw) To: Alan Modra; +Cc: binutils, libc-alpha, gcc, Tulio Magno Quites Machado Filho * Alan Modra: > On Mon, Sep 23, 2019 at 11:14:12AM +0200, Florian Weimer wrote: >> * 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: >> >> > 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? > > The idea was to allow lusers to do the same as they can on other > architectures, to minimise the number of bug reports saying "but I can > do this on x86". > > Hmm, I just checked. > $ gcc -shared -fPIC -ftls-model=local-exec -o thread.so ~/src/tmp/thread.c > /usr/bin/ld: /tmp/ccoXMrxD.o: relocation R_X86_64_TPOFF32 against > symbol `p' can not be used when making a shared object; recompile with > -fPIC It works with -m32. In theory, we still have DT_TEXTREL support for x86-64 in the loader, but I think BFD ld at least does not really support it. Since x86-64 only has 32-bit displacements, text relocations suffer from similar limitations as they would on POWER, so this looks to me mostly like a historical accident (like the existing text relocations that are recognized by the loader on POWER ELFv2). Going forward, I'll assume that we won't need any loader changes on POWER, and will not promote text relocations, either. It's nice that there isn't something left to do for us for once. ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2019-09-23 10:01 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-09-23 7:43 POWER PC-relative addressing and new text relocations Florian Weimer 2019-09-23 8:31 ` Alan Modra 2019-09-23 8:37 ` Florian Weimer 2019-09-23 9:06 ` Alan Modra 2019-09-23 9:14 ` Florian Weimer 2019-09-23 9:53 ` Alan Modra 2019-09-23 10:01 ` Florian Weimer
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).