* 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).