[RFC][PATCH] APX: Add R_X86_64_CODE_4_GOTTPOFF

30 views
Skip to first unread message

H.J. Lu

unread,
Sep 5, 2023, 12:32:46 PM9/5/23
to x86-6...@googlegroups.com
For TLS instructions:

mov foo@gottpoff(%rip), %reg
add foo@gottpoff(%rip), %reg

add

#define R_X86_64_CODE_4_GOTTPOFF 44

if the instruction starts at 4 bytes before the relocation offset. This
should be used if reg is one of the additional general-purpose registers,
r16-r31, in Intel APX. It is similar to R_X86_64_GOTTPOFF and linker
optimization must take the different instruction encoding into account.
---
x86-64-ABI/object-files.tex | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/x86-64-ABI/object-files.tex b/x86-64-ABI/object-files.tex
index 2a2e315..9c4b9aa 100644
--- a/x86-64-ABI/object-files.tex
+++ b/x86-64-ABI/object-files.tex
@@ -487,6 +487,7 @@ or \texttt{Elf32_Rel} relocation entries.
\texttt{R_X86_64_GOTPCRELX} & 41 & \textit{word32} & \texttt{G + GOT + A - P} \\
\texttt{R_X86_64_REX_GOTPCRELX} & 42 & \textit{word32} & \texttt{G + GOT + A - P} \\
\texttt{R_X86_64_CODE_4_GOTPCRELX} & 43 & \textit{word32} & \texttt{G + GOT + A - P} \\
+ \texttt{R_X86_64_CODE_4_GOTTPOFF} & 44 & \textit{word32} & \\
\cline{1-4}
\multicolumn{4}{l}{\small $^\dagger$ This relocation is used only for LP64.}\\
\multicolumn{4}{l}{\small $^{\dagger\dagger}$ This relocation only
@@ -572,7 +573,11 @@ of the Thread-Local Storage ABI extensions and are documented in the
document called ``ELF Handling for Thread-Local
Storage''\footnote{This document is currently available via
\raggedright\url{http://www.akkadia.org/drepper/tls.pdf}}\index{Thread-Local
- Storage}. The relocations \texttt{R_X86_64_GOTPC32_TLSDESC},
+ Storage}. \texttt{R_X86_64_CODE_4_GOTTPOFF} should be generated,
+instead of \texttt{R_X86_64_GOTTPOFF}, if the instruction starts at 4
+bytes before the relocation offset and linker optimization must take the
+different instruction encoding into account. The relocations
+\texttt{R_X86_64_GOTPC32_TLSDESC},
\texttt{R_X86_64_TLSDESC_CALL} and \texttt{R_X86_64_TLSDESC} are also
used for Thread-Local Storage, but are not documented there as of this
writing. A description can be found in the document ``Thread-Local
--
2.41.0

Michael Matz

unread,
Sep 6, 2023, 8:48:58 AM9/6/23
to H.J. Lu, x86-6...@googlegroups.com
Hello,

On Tue, 5 Sep 2023, H.J. Lu wrote:

> For TLS instructions:
>
> mov foo@gottpoff(%rip), %reg
> add foo@gottpoff(%rip), %reg
>
> add
>
> #define R_X86_64_CODE_4_GOTTPOFF 44
>
> if the instruction starts at 4 bytes before the relocation offset. This
> should be used if reg is one of the additional general-purpose registers,
> r16-r31, in Intel APX. It is similar to R_X86_64_GOTTPOFF and linker
> optimization must take the different instruction encoding into account.

I wonder if we shouldn't then also add REX_GOTTPOFF (or CODE_3_GOTTPOFF)
now. The current code in ld.bfd simply looks at three bytes before the
reloc address and if it happens to be 0x4X assumes it's a REX byte. I.e.
same problem that GOTPCREL had before introduction of REX_GOTPCRELX. I
mean the current hack works in the wild, but shouldn't we try to make it
less hacky?

(Otherwise: in isolation the CODE_4_GOTTPOFF makes of course sense).


Ciao,
Michael.

H.J. Lu

unread,
Sep 7, 2023, 11:45:13 AM9/7/23
to Michael Matz, x86-6...@googlegroups.com
On Wed, Sep 6, 2023 at 5:48 AM Michael Matz <ma...@suse.de> wrote:
>
> Hello,
>
> On Tue, 5 Sep 2023, H.J. Lu wrote:
>
> > For TLS instructions:
> >
> > mov foo@gottpoff(%rip), %reg
> > add foo@gottpoff(%rip), %reg
> >
> > add
> >
> > #define R_X86_64_CODE_4_GOTTPOFF 44
> >
> > if the instruction starts at 4 bytes before the relocation offset. This
> > should be used if reg is one of the additional general-purpose registers,
> > r16-r31, in Intel APX. It is similar to R_X86_64_GOTTPOFF and linker
> > optimization must take the different instruction encoding into account.
>
> I wonder if we shouldn't then also add REX_GOTTPOFF (or CODE_3_GOTTPOFF)
> now. The current code in ld.bfd simply looks at three bytes before the
> reloc address and if it happens to be 0x4X assumes it's a REX byte. I.e.
> same problem that GOTPCREL had before introduction of REX_GOTPCRELX. I
> mean the current hack works in the wild, but shouldn't we try to make it
> less hacky?

Or we can add some wording to R_X86_64_GOTTPOFF to specify that
the instruction should start at 3 bytes before the relocation offset.

> (Otherwise: in isolation the CODE_4_GOTTPOFF makes of course sense).
>

Thanks.
--
H.J.

H.J. Lu

unread,
Sep 7, 2023, 12:19:00 PM9/7/23
to Michael Matz, x86-6...@googlegroups.com
On Thu, Sep 7, 2023 at 8:44 AM H.J. Lu <hjl....@gmail.com> wrote:
>
> On Wed, Sep 6, 2023 at 5:48 AM Michael Matz <ma...@suse.de> wrote:
> >
> > Hello,
> >
> > On Tue, 5 Sep 2023, H.J. Lu wrote:
> >
> > > For TLS instructions:
> > >
> > > mov foo@gottpoff(%rip), %reg
> > > add foo@gottpoff(%rip), %reg
> > >
> > > add
> > >
> > > #define R_X86_64_CODE_4_GOTTPOFF 44
> > >
> > > if the instruction starts at 4 bytes before the relocation offset. This
> > > should be used if reg is one of the additional general-purpose registers,
> > > r16-r31, in Intel APX. It is similar to R_X86_64_GOTTPOFF and linker
> > > optimization must take the different instruction encoding into account.
> >
> > I wonder if we shouldn't then also add REX_GOTTPOFF (or CODE_3_GOTTPOFF)
> > now. The current code in ld.bfd simply looks at three bytes before the
> > reloc address and if it happens to be 0x4X assumes it's a REX byte. I.e.
> > same problem that GOTPCREL had before introduction of REX_GOTPCRELX. I
> > mean the current hack works in the wild, but shouldn't we try to make it
> > less hacky?
>
> Or we can add some wording to R_X86_64_GOTTPOFF to specify that
> the instruction should start at 3 bytes before the relocation offset.

The psABI has been updated to reflect it:

https://gitlab.com/x86-psABIs/x86-64-ABI/-/merge_requests/47

> > (Otherwise: in isolation the CODE_4_GOTTPOFF makes of course sense).
> >

Here is the merge request:

https://gitlab.com/x86-psABIs/x86-64-ABI/-/merge_requests/48

Thanks.

--
H.J.
Reply all
Reply to author
Forward
0 new messages