[PATCH] ld: Allow R_X86_64_GOTPCREL for call *__tls_get_addr@GOTPCREL(%rip)

[PATCH] ld: Allow R_X86_64_GOTPCREL for call *__tls_get_addr@GOTPCREL(%rip)

[Fangrui Song]

_Thread_local int a;
int main() { return a; }

% gcc -fno-plt -fpic a.c -fuse-ld=bfd -Wa,-mrelax-relocations=no
/usr/bin/ld.bfd: /tmp/ccSSBgrg.o: TLS transition from R_X86_64_TLSGD to R_X86_64_GOTTPOFF against `a' at 0xd in section `.text' failed
/usr/bin/ld.bfd: failed to set dynamic section sizes: bad value
collect2: error: ld returned 1 exit status

This commit fixes the issue.

    PR ld/24784
    * bfd/elf64-x86-64.c (elf_x86_64_check_tls_transition): Allow
      R_X86_64_GOTPCREL.
---
 bfd/elf64-x86-64.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bfd/elf64-x86-64.c b/bfd/elf64-x86-64.c
index 914f82d0151..095fe2e0fe6 100644
--- a/bfd/elf64-x86-64.c
+++ b/bfd/elf64-x86-64.c
@@ -1241,7 +1241,7 @@ elf_x86_64_check_tls_transition (bfd *abfd,
 	  if (largepic)
 	    return r_type == R_X86_64_PLTOFF64;
 	  else if (indirect_call)
-	    return r_type == R_X86_64_GOTPCRELX;
+	    return (r_type == R_X86_64_GOTPCRELX || r_type == R_X86_64_GOTPCREL);
 	  else
 	    return (r_type == R_X86_64_PC32 || r_type == R_X86_64_PLT32);
 	}
-- 
2.39.0.314.g84b9a713c41-goog

Re: [PATCH] ld: Allow R_X86_64_GOTPCREL for call *__tls_get_addr@GOTPCREL(%rip)

[H.J. Lu]

On Thu, Jan 5, 2023 at 1:06 PM Fangrui Song via Binutils
<binutils@sourceware.org> wrote:
>
> _Thread_local int a;
> int main() { return a; }
>
> % gcc -fno-plt -fpic a.c -fuse-ld=bfd -Wa,-mrelax-relocations=no
> /usr/bin/ld.bfd: /tmp/ccSSBgrg.o: TLS transition from R_X86_64_TLSGD to R_X86_64_GOTTPOFF against `a' at 0xd in section `.text' failed
> /usr/bin/ld.bfd: failed to set dynamic section sizes: bad value
> collect2: error: ld returned 1 exit status
>
> This commit fixes the issue.
>
>     PR ld/24784
>     * bfd/elf64-x86-64.c (elf_x86_64_check_tls_transition): Allow
>       R_X86_64_GOTPCREL.
> ---
>  bfd/elf64-x86-64.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/bfd/elf64-x86-64.c b/bfd/elf64-x86-64.c
> index 914f82d0151..095fe2e0fe6 100644
> --- a/bfd/elf64-x86-64.c
> +++ b/bfd/elf64-x86-64.c
> @@ -1241,7 +1241,7 @@ elf_x86_64_check_tls_transition (bfd *abfd,
>           if (largepic)
>             return r_type == R_X86_64_PLTOFF64;
>           else if (indirect_call)
> -           return r_type == R_X86_64_GOTPCRELX;
> +           return (r_type == R_X86_64_GOTPCRELX || r_type == R_X86_64_GOTPCREL);
>           else
>             return (r_type == R_X86_64_PC32 || r_type == R_X86_64_PLT32);
>         }
> --
> 2.39.0.314.g84b9a713c41-goog
>

Since the new TLS sequence was added after R_X86_64_GOTPCRELX was
required for call, R_X86_64_GOTPCREL should be invalid in this TLS sequence.

-- 
H.J.

Re: [PATCH] ld: Allow R_X86_64_GOTPCREL for call *__tls_get_addr@GOTPCREL(%rip)

[Fangrui Song]

On Fri, Jan 6, 2023 at 9:04 AM H.J. Lu <hjl.tools@gmail.com> wrote:
>
> On Thu, Jan 5, 2023 at 1:06 PM Fangrui Song via Binutils
> <binutils@sourceware.org> wrote:
> >
> > _Thread_local int a;
> > int main() { return a; }
> >
> > % gcc -fno-plt -fpic a.c -fuse-ld=bfd -Wa,-mrelax-relocations=no
> > /usr/bin/ld.bfd: /tmp/ccSSBgrg.o: TLS transition from R_X86_64_TLSGD to R_X86_64_GOTTPOFF against `a' at 0xd in section `.text' failed
> > /usr/bin/ld.bfd: failed to set dynamic section sizes: bad value
> > collect2: error: ld returned 1 exit status
> >
> > This commit fixes the issue.
> >
> >     PR ld/24784
> >     * bfd/elf64-x86-64.c (elf_x86_64_check_tls_transition): Allow
> >       R_X86_64_GOTPCREL.
> > ---
> >  bfd/elf64-x86-64.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/bfd/elf64-x86-64.c b/bfd/elf64-x86-64.c
> > index 914f82d0151..095fe2e0fe6 100644
> > --- a/bfd/elf64-x86-64.c
> > +++ b/bfd/elf64-x86-64.c
> > @@ -1241,7 +1241,7 @@ elf_x86_64_check_tls_transition (bfd *abfd,
> >           if (largepic)
> >             return r_type == R_X86_64_PLTOFF64;
> >           else if (indirect_call)
> > -           return r_type == R_X86_64_GOTPCRELX;
> > +           return (r_type == R_X86_64_GOTPCRELX || r_type == R_X86_64_GOTPCREL);
> >           else
> >             return (r_type == R_X86_64_PC32 || r_type == R_X86_64_PLT32);
> >         }
> > --
> > 2.39.0.314.g84b9a713c41-goog
> >
>
> Since the new TLS sequence was added after R_X86_64_GOTPCRELX was
> required for call, R_X86_64_GOTPCREL should be invalid in this TLS sequence.
>
> --
> H.J.

I have multiple arguments (albeit no single one is very strong) that
this 1-deletion-1-addition change provides benefits for users (IMHO
with no burden to binutils at all).

Some projects may add -Wa,-mrelax-relocations=no to work around older
GNU ld. Then the project's toolchain requirement may increase and no
longer need to work around older GNU ld.
But a distribution may for some reason use a global -fno-plt (e.g.
Arch Linux) and then run into this TLS GD/LD->IE/LE optimization
issue.

rust src/ci/docker/host-x86_64/*musl/Dockerfile
openjdk/jdk19u make/autoconf/flags-cflags.m4 (this file appears to be
copied into quite a few projects)
Linux kernel arch/x86/boot/compressed/Makefile (not a good example as
it doesn't use TLS AFAICT)

R_X86_64_GOTPCREL isn't purely usefull. It may help linker design: for
R_X86_64_GOTPCRELX/R_X86_64_REX_GOTPCRELX, the linker can make a
decision upfront whether a GOT entry is needed
(this affects the size of .got, which may affect section layout and
whether other relocations may overflow).
This may increase risk of 32-bit relocation overflow.
R_X86_64_GOTPCREL can mitigate the risk while being aware to the user.

rustc somehow disables x86 relaxed relocations and defaults to `-Z
plt=no` and now relies on llvm-project to work around the GNU ld
compatibility issue.




-- 
宋方睿

Re: [PATCH] ld: Allow R_X86_64_GOTPCREL for call *__tls_get_addr@GOTPCREL(%rip)

[H.J. Lu]

On Fri, Jan 6, 2023 at 10:48 AM Fangrui Song <maskray@google.com> wrote:
>
> On Fri, Jan 6, 2023 at 9:04 AM H.J. Lu <hjl.tools@gmail.com> wrote:
> >
> > On Thu, Jan 5, 2023 at 1:06 PM Fangrui Song via Binutils
> > <binutils@sourceware.org> wrote:
> > >
> > > _Thread_local int a;
> > > int main() { return a; }
> > >
> > > % gcc -fno-plt -fpic a.c -fuse-ld=bfd -Wa,-mrelax-relocations=no
> > > /usr/bin/ld.bfd: /tmp/ccSSBgrg.o: TLS transition from R_X86_64_TLSGD to R_X86_64_GOTTPOFF against `a' at 0xd in section `.text' failed
> > > /usr/bin/ld.bfd: failed to set dynamic section sizes: bad value
> > > collect2: error: ld returned 1 exit status
> > >
> > > This commit fixes the issue.
> > >
> > >     PR ld/24784
> > >     * bfd/elf64-x86-64.c (elf_x86_64_check_tls_transition): Allow
> > >       R_X86_64_GOTPCREL.
> > > ---
> > >  bfd/elf64-x86-64.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/bfd/elf64-x86-64.c b/bfd/elf64-x86-64.c
> > > index 914f82d0151..095fe2e0fe6 100644
> > > --- a/bfd/elf64-x86-64.c
> > > +++ b/bfd/elf64-x86-64.c
> > > @@ -1241,7 +1241,7 @@ elf_x86_64_check_tls_transition (bfd *abfd,
> > >           if (largepic)
> > >             return r_type == R_X86_64_PLTOFF64;
> > >           else if (indirect_call)
> > > -           return r_type == R_X86_64_GOTPCRELX;
> > > +           return (r_type == R_X86_64_GOTPCRELX || r_type == R_X86_64_GOTPCREL);
> > >           else
> > >             return (r_type == R_X86_64_PC32 || r_type == R_X86_64_PLT32);
> > >         }
> > > --
> > > 2.39.0.314.g84b9a713c41-goog
> > >
> >
> > Since the new TLS sequence was added after R_X86_64_GOTPCRELX was
> > required for call, R_X86_64_GOTPCREL should be invalid in this TLS sequence.
> >
> > --
> > H.J.
>
> I have multiple arguments (albeit no single one is very strong) that
> this 1-deletion-1-addition change provides benefits for users (IMHO
> with no burden to binutils at all).
>
> Some projects may add -Wa,-mrelax-relocations=no to work around older
> GNU ld. Then the project's toolchain requirement may increase and no
> longer need to work around older GNU ld.
> But a distribution may for some reason use a global -fno-plt (e.g.
> Arch Linux) and then run into this TLS GD/LD->IE/LE optimization
> issue.
>
> rust src/ci/docker/host-x86_64/*musl/Dockerfile
> openjdk/jdk19u make/autoconf/flags-cflags.m4 (this file appears to be
> copied into quite a few projects)
> Linux kernel arch/x86/boot/compressed/Makefile (not a good example as
> it doesn't use TLS AFAICT)
>
> R_X86_64_GOTPCREL isn't purely usefull. It may help linker design: for
> R_X86_64_GOTPCRELX/R_X86_64_REX_GOTPCRELX, the linker can make a
> decision upfront whether a GOT entry is needed
> (this affects the size of .got, which may affect section layout and
> whether other relocations may overflow).
> This may increase risk of 32-bit relocation overflow.
> R_X86_64_GOTPCREL can mitigate the risk while being aware to the user.
>
> rustc somehow disables x86 relaxed relocations and defaults to `-Z

Why is that?

> plt=no` and now relies on llvm-project to work around the GNU ld
> compatibility issue.
>
>
>
>
> --
> 宋方睿



-- 
H.J.

Re: [PATCH] ld: Allow R_X86_64_GOTPCREL for call *__tls_get_addr@GOTPCREL(%rip)

[Fangrui Song]

 On Fri, Jan 6, 2023 at 1:14 PM H.J. Lu <hjl.tools@gmail.com> wrote:
>
> On Fri, Jan 6, 2023 at 10:48 AM Fangrui Song <maskray@google.com> wrote:
> >
> > On Fri, Jan 6, 2023 at 9:04 AM H.J. Lu <hjl.tools@gmail.com> wrote:
> > >
> > > On Thu, Jan 5, 2023 at 1:06 PM Fangrui Song via Binutils
> > > <binutils@sourceware.org> wrote:
> > > >
> > > > _Thread_local int a;
> > > > int main() { return a; }
> > > >
> > > > % gcc -fno-plt -fpic a.c -fuse-ld=bfd -Wa,-mrelax-relocations=no
> > > > /usr/bin/ld.bfd: /tmp/ccSSBgrg.o: TLS transition from R_X86_64_TLSGD to R_X86_64_GOTTPOFF against `a' at 0xd in section `.text' failed
> > > > /usr/bin/ld.bfd: failed to set dynamic section sizes: bad value
> > > > collect2: error: ld returned 1 exit status
> > > >
> > > > This commit fixes the issue.
> > > >
> > > >     PR ld/24784
> > > >     * bfd/elf64-x86-64.c (elf_x86_64_check_tls_transition): Allow
> > > >       R_X86_64_GOTPCREL.
> > > > ---
> > > >  bfd/elf64-x86-64.c | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/bfd/elf64-x86-64.c b/bfd/elf64-x86-64.c
> > > > index 914f82d0151..095fe2e0fe6 100644
> > > > --- a/bfd/elf64-x86-64.c
> > > > +++ b/bfd/elf64-x86-64.c
> > > > @@ -1241,7 +1241,7 @@ elf_x86_64_check_tls_transition (bfd *abfd,
> > > >           if (largepic)
> > > >             return r_type == R_X86_64_PLTOFF64;
> > > >           else if (indirect_call)
> > > > -           return r_type == R_X86_64_GOTPCRELX;
> > > > +           return (r_type == R_X86_64_GOTPCRELX || r_type == R_X86_64_GOTPCREL);
> > > >           else
> > > >             return (r_type == R_X86_64_PC32 || r_type == R_X86_64_PLT32);
> > > >         }
> > > > --
> > > > 2.39.0.314.g84b9a713c41-goog
> > > >
> > >
> > > Since the new TLS sequence was added after R_X86_64_GOTPCRELX was
> > > required for call, R_X86_64_GOTPCREL should be invalid in this TLS sequence.
> > >
> > > --
> > > H.J.
> >
> > I have multiple arguments (albeit no single one is very strong) that
> > this 1-deletion-1-addition change provides benefits for users (IMHO
> > with no burden to binutils at all).
> >
> > Some projects may add -Wa,-mrelax-relocations=no to work around older
> > GNU ld. Then the project's toolchain requirement may increase and no
> > longer need to work around older GNU ld.
> > But a distribution may for some reason use a global -fno-plt (e.g.
> > Arch Linux) and then run into this TLS GD/LD->IE/LE optimization
> > issue.
> >
> > rust src/ci/docker/host-x86_64/*musl/Dockerfile
> > openjdk/jdk19u make/autoconf/flags-cflags.m4 (this file appears to be
> > copied into quite a few projects)
> > Linux kernel arch/x86/boot/compressed/Makefile (not a good example as
> > it doesn't use TLS AFAICT)
> >
> > R_X86_64_GOTPCREL isn't purely usefull. It may help linker design: for
> > R_X86_64_GOTPCRELX/R_X86_64_REX_GOTPCRELX, the linker can make a
> > decision upfront whether a GOT entry is needed
> > (this affects the size of .got, which may affect section layout and
> > whether other relocations may overflow).
> > This may increase risk of 32-bit relocation overflow.
> > R_X86_64_GOTPCREL can mitigate the risk while being aware to the user.
> >
> > rustc somehow disables x86 relaxed relocations and defaults to `-Z
>
> Why is that?

It's assuredly a rust's problem and I am trying to fix that in
https://github.com/rust-lang/rust/pull/106511

The  -Wa,-mrelax-relocations=no problem may affect more packages.

> > plt=no` and now relies on llvm-project to work around the GNU ld
> > compatibility issue.
> >
> >
> >
> >
> > --
> > 宋方睿
>
>
>
> --
> H.J.



-- 
宋方睿

Re: [PATCH] ld: Allow R_X86_64_GOTPCREL for call *__tls_get_addr@GOTPCREL(%rip)

[H.J. Lu]

On Fri, Jan 6, 2023 at 1:25 PM Fangrui Song <maskray@google.com> wrote:
>
>  On Fri, Jan 6, 2023 at 1:14 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> >
> > On Fri, Jan 6, 2023 at 10:48 AM Fangrui Song <maskray@google.com> wrote:
> > >
> > > On Fri, Jan 6, 2023 at 9:04 AM H.J. Lu <hjl.tools@gmail.com> wrote:
> > > >
> > > > On Thu, Jan 5, 2023 at 1:06 PM Fangrui Song via Binutils
> > > > <binutils@sourceware.org> wrote:
> > > > >
> > > > > _Thread_local int a;
> > > > > int main() { return a; }
> > > > >
> > > > > % gcc -fno-plt -fpic a.c -fuse-ld=bfd -Wa,-mrelax-relocations=no
> > > > > /usr/bin/ld.bfd: /tmp/ccSSBgrg.o: TLS transition from R_X86_64_TLSGD to R_X86_64_GOTTPOFF against `a' at 0xd in section `.text' failed
> > > > > /usr/bin/ld.bfd: failed to set dynamic section sizes: bad value
> > > > > collect2: error: ld returned 1 exit status
> > > > >
> > > > > This commit fixes the issue.
> > > > >
> > > > >     PR ld/24784
> > > > >     * bfd/elf64-x86-64.c (elf_x86_64_check_tls_transition): Allow
> > > > >       R_X86_64_GOTPCREL.
> > > > > ---
> > > > >  bfd/elf64-x86-64.c | 2 +-
> > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/bfd/elf64-x86-64.c b/bfd/elf64-x86-64.c
> > > > > index 914f82d0151..095fe2e0fe6 100644
> > > > > --- a/bfd/elf64-x86-64.c
> > > > > +++ b/bfd/elf64-x86-64.c
> > > > > @@ -1241,7 +1241,7 @@ elf_x86_64_check_tls_transition (bfd *abfd,
> > > > >           if (largepic)
> > > > >             return r_type == R_X86_64_PLTOFF64;
> > > > >           else if (indirect_call)
> > > > > -           return r_type == R_X86_64_GOTPCRELX;
> > > > > +           return (r_type == R_X86_64_GOTPCRELX || r_type == R_X86_64_GOTPCREL);
> > > > >           else
> > > > >             return (r_type == R_X86_64_PC32 || r_type == R_X86_64_PLT32);
> > > > >         }
> > > > > --
> > > > > 2.39.0.314.g84b9a713c41-goog
> > > > >
> > > >
> > > > Since the new TLS sequence was added after R_X86_64_GOTPCRELX was
> > > > required for call, R_X86_64_GOTPCREL should be invalid in this TLS sequence.
> > > >
> > > > --
> > > > H.J.
> > >
> > > I have multiple arguments (albeit no single one is very strong) that
> > > this 1-deletion-1-addition change provides benefits for users (IMHO
> > > with no burden to binutils at all).
> > >
> > > Some projects may add -Wa,-mrelax-relocations=no to work around older
> > > GNU ld. Then the project's toolchain requirement may increase and no
> > > longer need to work around older GNU ld.
> > > But a distribution may for some reason use a global -fno-plt (e.g.
> > > Arch Linux) and then run into this TLS GD/LD->IE/LE optimization
> > > issue.
> > >
> > > rust src/ci/docker/host-x86_64/*musl/Dockerfile
> > > openjdk/jdk19u make/autoconf/flags-cflags.m4 (this file appears to be
> > > copied into quite a few projects)
> > > Linux kernel arch/x86/boot/compressed/Makefile (not a good example as
> > > it doesn't use TLS AFAICT)
> > >
> > > R_X86_64_GOTPCREL isn't purely usefull. It may help linker design: for
> > > R_X86_64_GOTPCRELX/R_X86_64_REX_GOTPCRELX, the linker can make a
> > > decision upfront whether a GOT entry is needed
> > > (this affects the size of .got, which may affect section layout and
> > > whether other relocations may overflow).
> > > This may increase risk of 32-bit relocation overflow.
> > > R_X86_64_GOTPCREL can mitigate the risk while being aware to the user.
> > >
> > > rustc somehow disables x86 relaxed relocations and defaults to `-Z
> >
> > Why is that?
>
> It's assuredly a rust's problem and I am trying to fix that in
> https://github.com/rust-lang/rust/pull/106511
>
> The  -Wa,-mrelax-relocations=no problem may affect more packages.

-mrelax-relocations=no should be a workaround for the older linker.   It
shouldn't be used with the current linker.

> > > plt=no` and now relies on llvm-project to work around the GNU ld
> > > compatibility issue.
> > >
> > >
> > >
> > >
> > > --
> > > 宋方睿
> >
> >
> >
> > --
> > H.J.
>
>
>
> --
> 宋方睿



-- 
H.J.

Re: [PATCH] ld: Allow R_X86_64_GOTPCREL for call *__tls_get_addr@GOTPCREL(%rip)

[Fangrui Song]

On Fri, Jan 6, 2023 at 1:27 PM H.J. Lu <hjl.tools@gmail.com> wrote:
>
> On Fri, Jan 6, 2023 at 1:25 PM Fangrui Song <maskray@google.com> wrote:
> >
> >  On Fri, Jan 6, 2023 at 1:14 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> > >
> > > On Fri, Jan 6, 2023 at 10:48 AM Fangrui Song <maskray@google.com> wrote:
> > > >
> > > > On Fri, Jan 6, 2023 at 9:04 AM H.J. Lu <hjl.tools@gmail.com> wrote:
> > > > >
> > > > > On Thu, Jan 5, 2023 at 1:06 PM Fangrui Song via Binutils
> > > > > <binutils@sourceware.org> wrote:
> > > > > >
> > > > > > _Thread_local int a;
> > > > > > int main() { return a; }
> > > > > >
> > > > > > % gcc -fno-plt -fpic a.c -fuse-ld=bfd -Wa,-mrelax-relocations=no
> > > > > > /usr/bin/ld.bfd: /tmp/ccSSBgrg.o: TLS transition from R_X86_64_TLSGD to R_X86_64_GOTTPOFF against `a' at 0xd in section `.text' failed
> > > > > > /usr/bin/ld.bfd: failed to set dynamic section sizes: bad value
> > > > > > collect2: error: ld returned 1 exit status
> > > > > >
> > > > > > This commit fixes the issue.
> > > > > >
> > > > > >     PR ld/24784
> > > > > >     * bfd/elf64-x86-64.c (elf_x86_64_check_tls_transition): Allow
> > > > > >       R_X86_64_GOTPCREL.
> > > > > > ---
> > > > > >  bfd/elf64-x86-64.c | 2 +-
> > > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/bfd/elf64-x86-64.c b/bfd/elf64-x86-64.c
> > > > > > index 914f82d0151..095fe2e0fe6 100644
> > > > > > --- a/bfd/elf64-x86-64.c
> > > > > > +++ b/bfd/elf64-x86-64.c
> > > > > > @@ -1241,7 +1241,7 @@ elf_x86_64_check_tls_transition (bfd *abfd,
> > > > > >           if (largepic)
> > > > > >             return r_type == R_X86_64_PLTOFF64;
> > > > > >           else if (indirect_call)
> > > > > > -           return r_type == R_X86_64_GOTPCRELX;
> > > > > > +           return (r_type == R_X86_64_GOTPCRELX || r_type == R_X86_64_GOTPCREL);
> > > > > >           else
> > > > > >             return (r_type == R_X86_64_PC32 || r_type == R_X86_64_PLT32);
> > > > > >         }
> > > > > > --
> > > > > > 2.39.0.314.g84b9a713c41-goog
> > > > > >
> > > > >
> > > > > Since the new TLS sequence was added after R_X86_64_GOTPCRELX was
> > > > > required for call, R_X86_64_GOTPCREL should be invalid in this TLS sequence.
> > > > >
> > > > > --
> > > > > H.J.
> > > >
> > > > I have multiple arguments (albeit no single one is very strong) that
> > > > this 1-deletion-1-addition change provides benefits for users (IMHO
> > > > with no burden to binutils at all).
> > > >
> > > > Some projects may add -Wa,-mrelax-relocations=no to work around older
> > > > GNU ld. Then the project's toolchain requirement may increase and no
> > > > longer need to work around older GNU ld.
> > > > But a distribution may for some reason use a global -fno-plt (e.g.
> > > > Arch Linux) and then run into this TLS GD/LD->IE/LE optimization
> > > > issue.
> > > >
> > > > rust src/ci/docker/host-x86_64/*musl/Dockerfile
> > > > openjdk/jdk19u make/autoconf/flags-cflags.m4 (this file appears to be
> > > > copied into quite a few projects)
> > > > Linux kernel arch/x86/boot/compressed/Makefile (not a good example as
> > > > it doesn't use TLS AFAICT)
> > > >
> > > > R_X86_64_GOTPCREL isn't purely usefull. It may help linker design: for
> > > > R_X86_64_GOTPCRELX/R_X86_64_REX_GOTPCRELX, the linker can make a
> > > > decision upfront whether a GOT entry is needed
> > > > (this affects the size of .got, which may affect section layout and
> > > > whether other relocations may overflow).
> > > > This may increase risk of 32-bit relocation overflow.
> > > > R_X86_64_GOTPCREL can mitigate the risk while being aware to the user.
> > > >
> > > > rustc somehow disables x86 relaxed relocations and defaults to `-Z
> > >
> > > Why is that?
> >
> > It's assuredly a rust's problem and I am trying to fix that in
> > https://github.com/rust-lang/rust/pull/106511
> >
> > The  -Wa,-mrelax-relocations=no problem may affect more packages.
>
> -mrelax-relocations=no should be a workaround for the older linker.   It
> shouldn't be used with the current linker.

A project may choose to work with many linker versions.
For simplicity, before it decides to drop compatibility with GNU
ld<2.26 (AIUI GOTPCRELX was supported in 2.26),
it may unconditionally add -Wa,-mrelax-relocations=no, instead of
doing configure work to check linker support.

Now a user may use -fno-plt (Arch Linux, rustc, maybe Alpine) and run
into the aforementioned TLS problem.

This 1-deletion-1-addition change can address this issue with no
maintenance burden on binutils side in my opinion,
so I made this patch.

The linker design I described is true as well. Whether GOTPCRELX leads
to a GOT entry can be decided at relocation scanning time, before the
section layout is decided.
Users may make a conscious decision to use GOTPCREL to avoid potential
relocation overflow risk.

GOTPCREL isn't really dead. It can be used with Intel LAM and tagged
global variables (with non-zero high address bits)
https://reviews.llvm.org/D111343
GOTPCREL instead of GOTPCRELX makes it clear an instruction
referencing the variable isn't supposed to be relaxed.

> > > > plt=no` and now relies on llvm-project to work around the GNU ld
> > > > compatibility issue.
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > 宋方睿
> > >
> > >
> > >
> > > --
> > > H.J.
> >
> >
> >
> > --
> > 宋方睿
>
>
>
> --
> H.J.



-- 
宋方睿

Re: [PATCH] ld: Allow R_X86_64_GOTPCREL for call *__tls_get_addr@GOTPCREL(%rip)

[H.J. Lu]

On Fri, Jan 6, 2023 at 1:44 PM Fangrui Song <maskray@google.com> wrote:
>
> On Fri, Jan 6, 2023 at 1:27 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> >
> > On Fri, Jan 6, 2023 at 1:25 PM Fangrui Song <maskray@google.com> wrote:
> > >
> > >  On Fri, Jan 6, 2023 at 1:14 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> > > >
> > > > On Fri, Jan 6, 2023 at 10:48 AM Fangrui Song <maskray@google.com> wrote:
> > > > >
> > > > > On Fri, Jan 6, 2023 at 9:04 AM H.J. Lu <hjl.tools@gmail.com> wrote:
> > > > > >
> > > > > > On Thu, Jan 5, 2023 at 1:06 PM Fangrui Song via Binutils
> > > > > > <binutils@sourceware.org> wrote:
> > > > > > >
> > > > > > > _Thread_local int a;
> > > > > > > int main() { return a; }
> > > > > > >
> > > > > > > % gcc -fno-plt -fpic a.c -fuse-ld=bfd -Wa,-mrelax-relocations=no
> > > > > > > /usr/bin/ld.bfd: /tmp/ccSSBgrg.o: TLS transition from R_X86_64_TLSGD to R_X86_64_GOTTPOFF against `a' at 0xd in section `.text' failed
> > > > > > > /usr/bin/ld.bfd: failed to set dynamic section sizes: bad value
> > > > > > > collect2: error: ld returned 1 exit status
> > > > > > >
> > > > > > > This commit fixes the issue.
> > > > > > >
> > > > > > >     PR ld/24784
> > > > > > >     * bfd/elf64-x86-64.c (elf_x86_64_check_tls_transition): Allow
> > > > > > >       R_X86_64_GOTPCREL.
> > > > > > > ---
> > > > > > >  bfd/elf64-x86-64.c | 2 +-
> > > > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > > >
> > > > > > > diff --git a/bfd/elf64-x86-64.c b/bfd/elf64-x86-64.c
> > > > > > > index 914f82d0151..095fe2e0fe6 100644
> > > > > > > --- a/bfd/elf64-x86-64.c
> > > > > > > +++ b/bfd/elf64-x86-64.c
> > > > > > > @@ -1241,7 +1241,7 @@ elf_x86_64_check_tls_transition (bfd *abfd,
> > > > > > >           if (largepic)
> > > > > > >             return r_type == R_X86_64_PLTOFF64;
> > > > > > >           else if (indirect_call)
> > > > > > > -           return r_type == R_X86_64_GOTPCRELX;
> > > > > > > +           return (r_type == R_X86_64_GOTPCRELX || r_type == R_X86_64_GOTPCREL);
> > > > > > >           else
> > > > > > >             return (r_type == R_X86_64_PC32 || r_type == R_X86_64_PLT32);
> > > > > > >         }
> > > > > > > --
> > > > > > > 2.39.0.314.g84b9a713c41-goog
> > > > > > >
> > > > > >
> > > > > > Since the new TLS sequence was added after R_X86_64_GOTPCRELX was
> > > > > > required for call, R_X86_64_GOTPCREL should be invalid in this TLS sequence.
> > > > > >
> > > > > > --
> > > > > > H.J.
> > > > >
> > > > > I have multiple arguments (albeit no single one is very strong) that
> > > > > this 1-deletion-1-addition change provides benefits for users (IMHO
> > > > > with no burden to binutils at all).
> > > > >
> > > > > Some projects may add -Wa,-mrelax-relocations=no to work around older
> > > > > GNU ld. Then the project's toolchain requirement may increase and no
> > > > > longer need to work around older GNU ld.
> > > > > But a distribution may for some reason use a global -fno-plt (e.g.
> > > > > Arch Linux) and then run into this TLS GD/LD->IE/LE optimization
> > > > > issue.
> > > > >
> > > > > rust src/ci/docker/host-x86_64/*musl/Dockerfile
> > > > > openjdk/jdk19u make/autoconf/flags-cflags.m4 (this file appears to be
> > > > > copied into quite a few projects)
> > > > > Linux kernel arch/x86/boot/compressed/Makefile (not a good example as
> > > > > it doesn't use TLS AFAICT)
> > > > >
> > > > > R_X86_64_GOTPCREL isn't purely usefull. It may help linker design: for
> > > > > R_X86_64_GOTPCRELX/R_X86_64_REX_GOTPCRELX, the linker can make a
> > > > > decision upfront whether a GOT entry is needed
> > > > > (this affects the size of .got, which may affect section layout and
> > > > > whether other relocations may overflow).
> > > > > This may increase risk of 32-bit relocation overflow.
> > > > > R_X86_64_GOTPCREL can mitigate the risk while being aware to the user.
> > > > >
> > > > > rustc somehow disables x86 relaxed relocations and defaults to `-Z
> > > >
> > > > Why is that?
> > >
> > > It's assuredly a rust's problem and I am trying to fix that in
> > > https://github.com/rust-lang/rust/pull/106511
> > >
> > > The  -Wa,-mrelax-relocations=no problem may affect more packages.
> >
> > -mrelax-relocations=no should be a workaround for the older linker.   It
> > shouldn't be used with the current linker.
>
> A project may choose to work with many linker versions.
> For simplicity, before it decides to drop compatibility with GNU
> ld<2.26 (AIUI GOTPCRELX was supported in 2.26),
> it may unconditionally add -Wa,-mrelax-relocations=no, instead of

-mrelax-relocations=no is only supported with the newer binutils.

> doing configure work to check linker support.

The TLS sequence from -fno-plt doesn't work for the older linker.
The older linker support should be dropped for -fno-plt.

> Now a user may use -fno-plt (Arch Linux, rustc, maybe Alpine) and run
> into the aforementioned TLS problem.
>
> This 1-deletion-1-addition change can address this issue with no
> maintenance burden on binutils side in my opinion,
> so I made this patch.
>
> The linker design I described is true as well. Whether GOTPCRELX leads
> to a GOT entry can be decided at relocation scanning time, before the
> section layout is decided.
> Users may make a conscious decision to use GOTPCREL to avoid potential
> relocation overflow risk.
>
> GOTPCREL isn't really dead. It can be used with Intel LAM and tagged
> global variables (with non-zero high address bits)
> https://reviews.llvm.org/D111343
> GOTPCREL instead of GOTPCRELX makes it clear an instruction
> referencing the variable isn't supposed to be relaxed.

The address of the local symbol, foo, in

movq foo@GOTPCREL(%rip), %rax

is assigned by the linker.  I am not sure how the tag is involved here.
Besides, it is the call instruction here.

> > > > > plt=no` and now relies on llvm-project to work around the GNU ld
> > > > > compatibility issue.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > 宋方睿
> > > >
> > > >
> > > >
> > > > --
> > > > H.J.
> > >
> > >
> > >
> > > --
> > > 宋方睿
> >
> >
> >
> > --
> > H.J.
>
>
>
> --
> 宋方睿



-- 
H.J.

Re: [PATCH] ld: Allow R_X86_64_GOTPCREL for call *__tls_get_addr@GOTPCREL(%rip)

[Fangrui Song]

 On Fri, Jan 6, 2023 at 2:42 PM H.J. Lu <hjl.tools@gmail.com> wrote:
>
> On Fri, Jan 6, 2023 at 1:44 PM Fangrui Song <maskray@google.com> wrote:
> >
> > On Fri, Jan 6, 2023 at 1:27 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> > >
> > > On Fri, Jan 6, 2023 at 1:25 PM Fangrui Song <maskray@google.com> wrote:
> > > >
> > > >  On Fri, Jan 6, 2023 at 1:14 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> > > > >
> > > > > On Fri, Jan 6, 2023 at 10:48 AM Fangrui Song <maskray@google.com> wrote:
> > > > > >
> > > > > > On Fri, Jan 6, 2023 at 9:04 AM H.J. Lu <hjl.tools@gmail.com> wrote:
> > > > > > >
> > > > > > > On Thu, Jan 5, 2023 at 1:06 PM Fangrui Song via Binutils
> > > > > > > <binutils@sourceware.org> wrote:
> > > > > > > >
> > > > > > > > _Thread_local int a;
> > > > > > > > int main() { return a; }
> > > > > > > >
> > > > > > > > % gcc -fno-plt -fpic a.c -fuse-ld=bfd -Wa,-mrelax-relocations=no
> > > > > > > > /usr/bin/ld.bfd: /tmp/ccSSBgrg.o: TLS transition from R_X86_64_TLSGD to R_X86_64_GOTTPOFF against `a' at 0xd in section `.text' failed
> > > > > > > > /usr/bin/ld.bfd: failed to set dynamic section sizes: bad value
> > > > > > > > collect2: error: ld returned 1 exit status
> > > > > > > >
> > > > > > > > This commit fixes the issue.
> > > > > > > >
> > > > > > > >     PR ld/24784
> > > > > > > >     * bfd/elf64-x86-64.c (elf_x86_64_check_tls_transition): Allow
> > > > > > > >       R_X86_64_GOTPCREL.
> > > > > > > > ---
> > > > > > > >  bfd/elf64-x86-64.c | 2 +-
> > > > > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > > > >
> > > > > > > > diff --git a/bfd/elf64-x86-64.c b/bfd/elf64-x86-64.c
> > > > > > > > index 914f82d0151..095fe2e0fe6 100644
> > > > > > > > --- a/bfd/elf64-x86-64.c
> > > > > > > > +++ b/bfd/elf64-x86-64.c
> > > > > > > > @@ -1241,7 +1241,7 @@ elf_x86_64_check_tls_transition (bfd *abfd,
> > > > > > > >           if (largepic)
> > > > > > > >             return r_type == R_X86_64_PLTOFF64;
> > > > > > > >           else if (indirect_call)
> > > > > > > > -           return r_type == R_X86_64_GOTPCRELX;
> > > > > > > > +           return (r_type == R_X86_64_GOTPCRELX || r_type == R_X86_64_GOTPCREL);
> > > > > > > >           else
> > > > > > > >             return (r_type == R_X86_64_PC32 || r_type == R_X86_64_PLT32);
> > > > > > > >         }
> > > > > > > > --
> > > > > > > > 2.39.0.314.g84b9a713c41-goog
> > > > > > > >
> > > > > > >
> > > > > > > Since the new TLS sequence was added after R_X86_64_GOTPCRELX was
> > > > > > > required for call, R_X86_64_GOTPCREL should be invalid in this TLS sequence.
> > > > > > >
> > > > > > > --
> > > > > > > H.J.
> > > > > >
> > > > > > I have multiple arguments (albeit no single one is very strong) that
> > > > > > this 1-deletion-1-addition change provides benefits for users (IMHO
> > > > > > with no burden to binutils at all).
> > > > > >
> > > > > > Some projects may add -Wa,-mrelax-relocations=no to work around older
> > > > > > GNU ld. Then the project's toolchain requirement may increase and no
> > > > > > longer need to work around older GNU ld.
> > > > > > But a distribution may for some reason use a global -fno-plt (e.g.
> > > > > > Arch Linux) and then run into this TLS GD/LD->IE/LE optimization
> > > > > > issue.
> > > > > >
> > > > > > rust src/ci/docker/host-x86_64/*musl/Dockerfile
> > > > > > openjdk/jdk19u make/autoconf/flags-cflags.m4 (this file appears to be
> > > > > > copied into quite a few projects)
> > > > > > Linux kernel arch/x86/boot/compressed/Makefile (not a good example as
> > > > > > it doesn't use TLS AFAICT)
> > > > > >
> > > > > > R_X86_64_GOTPCREL isn't purely usefull. It may help linker design: for
> > > > > > R_X86_64_GOTPCRELX/R_X86_64_REX_GOTPCRELX, the linker can make a
> > > > > > decision upfront whether a GOT entry is needed
> > > > > > (this affects the size of .got, which may affect section layout and
> > > > > > whether other relocations may overflow).
> > > > > > This may increase risk of 32-bit relocation overflow.
> > > > > > R_X86_64_GOTPCREL can mitigate the risk while being aware to the user.
> > > > > >
> > > > > > rustc somehow disables x86 relaxed relocations and defaults to `-Z
> > > > >
> > > > > Why is that?
> > > >
> > > > It's assuredly a rust's problem and I am trying to fix that in
> > > > https://github.com/rust-lang/rust/pull/106511
> > > >
> > > > The  -Wa,-mrelax-relocations=no problem may affect more packages.
> > >
> > > -mrelax-relocations=no should be a workaround for the older linker.   It
> > > shouldn't be used with the current linker.
> >
> > A project may choose to work with many linker versions.
> > For simplicity, before it decides to drop compatibility with GNU
> > ld<2.26 (AIUI GOTPCRELX was supported in 2.26),
> > it may unconditionally add -Wa,-mrelax-relocations=no, instead of
>
> -mrelax-relocations=no is only supported with the newer binutils.

The relocatable object file producer and the consumer may be on
different machines and use different binutils versions.
https://github.com/rust-lang/rust/commit/305aca86f9d8d132650b495f610f9abe5239fec6
added -Wa,-mrelax-relocations=no so that the relocatable object files
can be used on a user machine with an old ld.
https://github.com/IHaskell/IHaskell/issues/636 and
https://github.com/dcos/dcos/commit/facda25019e07051f501b39720b4e71049bd0030
likely use the same argument.

In other cases, the project may use -Wa,-mrelax-relocations=no with
Clang (where they assume a not-too-old version), but need to work with
system ld (which may be old).

> > doing configure work to check linker support.
>
> The TLS sequence from -fno-plt doesn't work for the older linker.
> The older linker support should be dropped for -fno-plt.
>
> > Now a user may use -fno-plt (Arch Linux, rustc, maybe Alpine) and run
> > into the aforementioned TLS problem.
> >
> > This 1-deletion-1-addition change can address this issue with no
> > maintenance burden on binutils side in my opinion,
> > so I made this patch.
> >
> > The linker design I described is true as well. Whether GOTPCRELX leads
> > to a GOT entry can be decided at relocation scanning time, before the
> > section layout is decided.
> > Users may make a conscious decision to use GOTPCREL to avoid potential
> > relocation overflow risk.
> >
> > GOTPCREL isn't really dead. It can be used with Intel LAM and tagged
> > global variables (with non-zero high address bits)
> > https://reviews.llvm.org/D111343
> > GOTPCREL instead of GOTPCRELX makes it clear an instruction
> > referencing the variable isn't supposed to be relaxed.
>
> The address of the local symbol, foo, in
>
> movq foo@GOTPCREL(%rip), %rax
>
> is assigned by the linker.  I am not sure how the tag is involved here.
> Besides, it is the call instruction here.

This is an auxiliary argument. I wanted to emphasize that GOTPCREL
isn't dead and did not intend to use it with this call instruction.
If GOTPCRELX is used and the distance between the current location and
the symbol is larger than 2**31, this will trigger a relocation
overflow.
This happens with tagged globals with non-zero high address bits.
A linker can fix the problem by avoiding relaxation, increasing the
size of .got . This requires that it scans relocations more than once.
If GOTPCRELX is decided upfront whether it needs relaxation or not, on
an arch which doesn't use range extension thunks like x86, technically
relocations can just be scanned once.

> > > > > > plt=no` and now relies on llvm-project to work around the GNU ld
> > > > > > compatibility issue.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > 宋方睿
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > H.J.
> > > >
> > > >
> > > >
> > > > --
> > > > 宋方睿
> > >
> > >
> > >
> > > --
> > > H.J.
> >
> >
> >
> > --
> > 宋方睿
>
>
>
> --
> H.J.



-- 
宋方睿

Re: [PATCH] ld: Allow R_X86_64_GOTPCREL for call *__tls_get_addr@GOTPCREL(%rip)

[H.J. Lu]

On Fri, Jan 6, 2023 at 3:02 PM Fangrui Song <maskray@google.com> wrote:
>
>  On Fri, Jan 6, 2023 at 2:42 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> >
> > On Fri, Jan 6, 2023 at 1:44 PM Fangrui Song <maskray@google.com> wrote:
> > >
> > > On Fri, Jan 6, 2023 at 1:27 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> > > >
> > > > On Fri, Jan 6, 2023 at 1:25 PM Fangrui Song <maskray@google.com> wrote:
> > > > >
> > > > >  On Fri, Jan 6, 2023 at 1:14 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> > > > > >
> > > > > > On Fri, Jan 6, 2023 at 10:48 AM Fangrui Song <maskray@google.com> wrote:
> > > > > > >
> > > > > > > On Fri, Jan 6, 2023 at 9:04 AM H.J. Lu <hjl.tools@gmail.com> wrote:
> > > > > > > >
> > > > > > > > On Thu, Jan 5, 2023 at 1:06 PM Fangrui Song via Binutils
> > > > > > > > <binutils@sourceware.org> wrote:
> > > > > > > > >
> > > > > > > > > _Thread_local int a;
> > > > > > > > > int main() { return a; }
> > > > > > > > >
> > > > > > > > > % gcc -fno-plt -fpic a.c -fuse-ld=bfd -Wa,-mrelax-relocations=no
> > > > > > > > > /usr/bin/ld.bfd: /tmp/ccSSBgrg.o: TLS transition from R_X86_64_TLSGD to R_X86_64_GOTTPOFF against `a' at 0xd in section `.text' failed
> > > > > > > > > /usr/bin/ld.bfd: failed to set dynamic section sizes: bad value
> > > > > > > > > collect2: error: ld returned 1 exit status
> > > > > > > > >
> > > > > > > > > This commit fixes the issue.
> > > > > > > > >
> > > > > > > > >     PR ld/24784
> > > > > > > > >     * bfd/elf64-x86-64.c (elf_x86_64_check_tls_transition): Allow
> > > > > > > > >       R_X86_64_GOTPCREL.
> > > > > > > > > ---
> > > > > > > > >  bfd/elf64-x86-64.c | 2 +-
> > > > > > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > > > > >
> > > > > > > > > diff --git a/bfd/elf64-x86-64.c b/bfd/elf64-x86-64.c
> > > > > > > > > index 914f82d0151..095fe2e0fe6 100644
> > > > > > > > > --- a/bfd/elf64-x86-64.c
> > > > > > > > > +++ b/bfd/elf64-x86-64.c
> > > > > > > > > @@ -1241,7 +1241,7 @@ elf_x86_64_check_tls_transition (bfd *abfd,
> > > > > > > > >           if (largepic)
> > > > > > > > >             return r_type == R_X86_64_PLTOFF64;
> > > > > > > > >           else if (indirect_call)
> > > > > > > > > -           return r_type == R_X86_64_GOTPCRELX;
> > > > > > > > > +           return (r_type == R_X86_64_GOTPCRELX || r_type == R_X86_64_GOTPCREL);
> > > > > > > > >           else
> > > > > > > > >             return (r_type == R_X86_64_PC32 || r_type == R_X86_64_PLT32);
> > > > > > > > >         }
> > > > > > > > > --
> > > > > > > > > 2.39.0.314.g84b9a713c41-goog
> > > > > > > > >
> > > > > > > >
> > > > > > > > Since the new TLS sequence was added after R_X86_64_GOTPCRELX was
> > > > > > > > required for call, R_X86_64_GOTPCREL should be invalid in this TLS sequence.
> > > > > > > >
> > > > > > > > --
> > > > > > > > H.J.
> > > > > > >
> > > > > > > I have multiple arguments (albeit no single one is very strong) that
> > > > > > > this 1-deletion-1-addition change provides benefits for users (IMHO
> > > > > > > with no burden to binutils at all).
> > > > > > >
> > > > > > > Some projects may add -Wa,-mrelax-relocations=no to work around older
> > > > > > > GNU ld. Then the project's toolchain requirement may increase and no
> > > > > > > longer need to work around older GNU ld.
> > > > > > > But a distribution may for some reason use a global -fno-plt (e.g.
> > > > > > > Arch Linux) and then run into this TLS GD/LD->IE/LE optimization
> > > > > > > issue.
> > > > > > >
> > > > > > > rust src/ci/docker/host-x86_64/*musl/Dockerfile
> > > > > > > openjdk/jdk19u make/autoconf/flags-cflags.m4 (this file appears to be
> > > > > > > copied into quite a few projects)
> > > > > > > Linux kernel arch/x86/boot/compressed/Makefile (not a good example as
> > > > > > > it doesn't use TLS AFAICT)
> > > > > > >
> > > > > > > R_X86_64_GOTPCREL isn't purely usefull. It may help linker design: for
> > > > > > > R_X86_64_GOTPCRELX/R_X86_64_REX_GOTPCRELX, the linker can make a
> > > > > > > decision upfront whether a GOT entry is needed
> > > > > > > (this affects the size of .got, which may affect section layout and
> > > > > > > whether other relocations may overflow).
> > > > > > > This may increase risk of 32-bit relocation overflow.
> > > > > > > R_X86_64_GOTPCREL can mitigate the risk while being aware to the user.
> > > > > > >
> > > > > > > rustc somehow disables x86 relaxed relocations and defaults to `-Z
> > > > > >
> > > > > > Why is that?
> > > > >
> > > > > It's assuredly a rust's problem and I am trying to fix that in
> > > > > https://github.com/rust-lang/rust/pull/106511
> > > > >
> > > > > The  -Wa,-mrelax-relocations=no problem may affect more packages.
> > > >
> > > > -mrelax-relocations=no should be a workaround for the older linker.   It
> > > > shouldn't be used with the current linker.
> > >
> > > A project may choose to work with many linker versions.
> > > For simplicity, before it decides to drop compatibility with GNU
> > > ld<2.26 (AIUI GOTPCRELX was supported in 2.26),
> > > it may unconditionally add -Wa,-mrelax-relocations=no, instead of
> >
> > -mrelax-relocations=no is only supported with the newer binutils.
>
> The relocatable object file producer and the consumer may be on
> different machines and use different binutils versions.
> https://github.com/rust-lang/rust/commit/305aca86f9d8d132650b495f610f9abe5239fec6
> added -Wa,-mrelax-relocations=no so that the relocatable object files
> can be used on a user machine with an old ld.

But -fno-plt may not work with the old linker.   For this matter,
-Wa,-mrelax-relocations=no doesn't work with ld today.  When
-Wa,-mrelax-relocations=no is used, no features from newer linkers
can be used.

> https://github.com/IHaskell/IHaskell/issues/636 and
> https://github.com/dcos/dcos/commit/facda25019e07051f501b39720b4e71049bd0030
> likely use the same argument.
>
> In other cases, the project may use -Wa,-mrelax-relocations=no with
> Clang (where they assume a not-too-old version), but need to work with
> system ld (which may be old).

This shouldn't happen with as and ld from the same binutils.

> > > doing configure work to check linker support.
> >
> > The TLS sequence from -fno-plt doesn't work for the older linker.
> > The older linker support should be dropped for -fno-plt.
> >
> > > Now a user may use -fno-plt (Arch Linux, rustc, maybe Alpine) and run
> > > into the aforementioned TLS problem.
> > >
> > > This 1-deletion-1-addition change can address this issue with no
> > > maintenance burden on binutils side in my opinion,
> > > so I made this patch.
> > >
> > > The linker design I described is true as well. Whether GOTPCRELX leads
> > > to a GOT entry can be decided at relocation scanning time, before the
> > > section layout is decided.
> > > Users may make a conscious decision to use GOTPCREL to avoid potential
> > > relocation overflow risk.
> > >
> > > GOTPCREL isn't really dead. It can be used with Intel LAM and tagged
> > > global variables (with non-zero high address bits)
> > > https://reviews.llvm.org/D111343
> > > GOTPCREL instead of GOTPCRELX makes it clear an instruction
> > > referencing the variable isn't supposed to be relaxed.
> >
> > The address of the local symbol, foo, in
> >
> > movq foo@GOTPCREL(%rip), %rax
> >
> > is assigned by the linker.  I am not sure how the tag is involved here.
> > Besides, it is the call instruction here.
>
> This is an auxiliary argument. I wanted to emphasize that GOTPCREL
> isn't dead and did not intend to use it with this call instruction.
> If GOTPCRELX is used and the distance between the current location and
> the symbol is larger than 2**31, this will trigger a relocation
> overflow.
>
> This happens with tagged globals with non-zero high address bits.

This sounds needing some linker changes to add tags to data variables.
I am not sure if GOTPCREL alone is sufficient.

> A linker can fix the problem by avoiding relaxation, increasing the
> size of .got . This requires that it scans relocations more than once.
> If GOTPCRELX is decided upfront whether it needs relaxation or not, on
> an arch which doesn't use range extension thunks like x86, technically
> relocations can just be scanned once.
>
> > > > > > > plt=no` and now relies on llvm-project to work around the GNU ld
> > > > > > > compatibility issue.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > 宋方睿
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > H.J.
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > 宋方睿
> > > >
> > > >
> > > >
> > > > --
> > > > H.J.
> > >
> > >
> > >
> > > --
> > > 宋方睿
> >
> >
> >
> > --
> > H.J.
>
>
>
> --
> 宋方睿



-- 
H.J.

Re: [PATCH] ld: Allow R_X86_64_GOTPCREL for call *__tls_get_addr@GOTPCREL(%rip)

[Fangrui Song]

On Fri, Jan 6, 2023 at 3:20 PM H.J. Lu <hjl.tools@gmail.com> wrote:
>
> On Fri, Jan 6, 2023 at 3:02 PM Fangrui Song <maskray@google.com> wrote:
> >
> >  On Fri, Jan 6, 2023 at 2:42 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> > >
> > > On Fri, Jan 6, 2023 at 1:44 PM Fangrui Song <maskray@google.com> wrote:
> > > >
> > > > On Fri, Jan 6, 2023 at 1:27 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> > > > >
> > > > > On Fri, Jan 6, 2023 at 1:25 PM Fangrui Song <maskray@google.com> wrote:
> > > > > >
> > > > > >  On Fri, Jan 6, 2023 at 1:14 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> > > > > > >
> > > > > > > On Fri, Jan 6, 2023 at 10:48 AM Fangrui Song <maskray@google.com> wrote:
> > > > > > > >
> > > > > > > > On Fri, Jan 6, 2023 at 9:04 AM H.J. Lu <hjl.tools@gmail.com> wrote:
> > > > > > > > >
> > > > > > > > > On Thu, Jan 5, 2023 at 1:06 PM Fangrui Song via Binutils
> > > > > > > > > <binutils@sourceware.org> wrote:
> > > > > > > > > >
> > > > > > > > > > _Thread_local int a;
> > > > > > > > > > int main() { return a; }
> > > > > > > > > >
> > > > > > > > > > % gcc -fno-plt -fpic a.c -fuse-ld=bfd -Wa,-mrelax-relocations=no
> > > > > > > > > > /usr/bin/ld.bfd: /tmp/ccSSBgrg.o: TLS transition from R_X86_64_TLSGD to R_X86_64_GOTTPOFF against `a' at 0xd in section `.text' failed
> > > > > > > > > > /usr/bin/ld.bfd: failed to set dynamic section sizes: bad value
> > > > > > > > > > collect2: error: ld returned 1 exit status
> > > > > > > > > >
> > > > > > > > > > This commit fixes the issue.
> > > > > > > > > >
> > > > > > > > > >     PR ld/24784
> > > > > > > > > >     * bfd/elf64-x86-64.c (elf_x86_64_check_tls_transition): Allow
> > > > > > > > > >       R_X86_64_GOTPCREL.
> > > > > > > > > > ---
> > > > > > > > > >  bfd/elf64-x86-64.c | 2 +-
> > > > > > > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > > > > > >
> > > > > > > > > > diff --git a/bfd/elf64-x86-64.c b/bfd/elf64-x86-64.c
> > > > > > > > > > index 914f82d0151..095fe2e0fe6 100644
> > > > > > > > > > --- a/bfd/elf64-x86-64.c
> > > > > > > > > > +++ b/bfd/elf64-x86-64.c
> > > > > > > > > > @@ -1241,7 +1241,7 @@ elf_x86_64_check_tls_transition (bfd *abfd,
> > > > > > > > > >           if (largepic)
> > > > > > > > > >             return r_type == R_X86_64_PLTOFF64;
> > > > > > > > > >           else if (indirect_call)
> > > > > > > > > > -           return r_type == R_X86_64_GOTPCRELX;
> > > > > > > > > > +           return (r_type == R_X86_64_GOTPCRELX || r_type == R_X86_64_GOTPCREL);
> > > > > > > > > >           else
> > > > > > > > > >             return (r_type == R_X86_64_PC32 || r_type == R_X86_64_PLT32);
> > > > > > > > > >         }
> > > > > > > > > > --
> > > > > > > > > > 2.39.0.314.g84b9a713c41-goog
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > Since the new TLS sequence was added after R_X86_64_GOTPCRELX was
> > > > > > > > > required for call, R_X86_64_GOTPCREL should be invalid in this TLS sequence.
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > H.J.
> > > > > > > >
> > > > > > > > I have multiple arguments (albeit no single one is very strong) that
> > > > > > > > this 1-deletion-1-addition change provides benefits for users (IMHO
> > > > > > > > with no burden to binutils at all).
> > > > > > > >
> > > > > > > > Some projects may add -Wa,-mrelax-relocations=no to work around older
> > > > > > > > GNU ld. Then the project's toolchain requirement may increase and no
> > > > > > > > longer need to work around older GNU ld.
> > > > > > > > But a distribution may for some reason use a global -fno-plt (e.g.
> > > > > > > > Arch Linux) and then run into this TLS GD/LD->IE/LE optimization
> > > > > > > > issue.
> > > > > > > >
> > > > > > > > rust src/ci/docker/host-x86_64/*musl/Dockerfile
> > > > > > > > openjdk/jdk19u make/autoconf/flags-cflags.m4 (this file appears to be
> > > > > > > > copied into quite a few projects)
> > > > > > > > Linux kernel arch/x86/boot/compressed/Makefile (not a good example as
> > > > > > > > it doesn't use TLS AFAICT)
> > > > > > > >
> > > > > > > > R_X86_64_GOTPCREL isn't purely usefull. It may help linker design: for
> > > > > > > > R_X86_64_GOTPCRELX/R_X86_64_REX_GOTPCRELX, the linker can make a
> > > > > > > > decision upfront whether a GOT entry is needed
> > > > > > > > (this affects the size of .got, which may affect section layout and
> > > > > > > > whether other relocations may overflow).
> > > > > > > > This may increase risk of 32-bit relocation overflow.
> > > > > > > > R_X86_64_GOTPCREL can mitigate the risk while being aware to the user.
> > > > > > > >
> > > > > > > > rustc somehow disables x86 relaxed relocations and defaults to `-Z
> > > > > > >
> > > > > > > Why is that?
> > > > > >
> > > > > > It's assuredly a rust's problem and I am trying to fix that in
> > > > > > https://github.com/rust-lang/rust/pull/106511
> > > > > >
> > > > > > The  -Wa,-mrelax-relocations=no problem may affect more packages.
> > > > >
> > > > > -mrelax-relocations=no should be a workaround for the older linker.   It
> > > > > shouldn't be used with the current linker.
> > > >
> > > > A project may choose to work with many linker versions.
> > > > For simplicity, before it decides to drop compatibility with GNU
> > > > ld<2.26 (AIUI GOTPCRELX was supported in 2.26),
> > > > it may unconditionally add -Wa,-mrelax-relocations=no, instead of
> > >
> > > -mrelax-relocations=no is only supported with the newer binutils.
> >
> > The relocatable object file producer and the consumer may be on
> > different machines and use different binutils versions.
> > https://github.com/rust-lang/rust/commit/305aca86f9d8d132650b495f610f9abe5239fec6
> > added -Wa,-mrelax-relocations=no so that the relocatable object files
> > can be used on a user machine with an old ld.
>
> But -fno-plt may not work with the old linker.   For this matter,
> -Wa,-mrelax-relocations=no doesn't work with ld today.  When
> -Wa,-mrelax-relocations=no is used, no features from newer linkers
> can be used.

A project may add -Wa,-mrelax-relocations=no so that its prebuilt
relocatable object files can be linked on a machine with old ld.

A distribution (like Arch Linux and rust) using new ld may decide to
use -fno-plt globally. If they don't strip or override the project
-Wa,-mrelax-relocations=no,
they may run into the -fpic -fno-plt -Wa,-mrelax-relocations=no incompatibility.

In the GCC/gas model, GCC doesn't know whether its emitted assembly
will be used with -mrelax-relocations=no.
GCC just emits the -fno-plt form of TLS GD/LD code sequence. If the
assembly is fed into gas with -mrelax-relocations=no, the output will
be broken with current ld.

I have tested some TLS examples and this simple patch work. One can
argue that GNU ld either suppresses GD/LD=>IE/LE optimization or
support this old relocation type.
It appears that supporting the old relocation type is the simplest approach.

> > https://github.com/IHaskell/IHaskell/issues/636 and
> > https://github.com/dcos/dcos/commit/facda25019e07051f501b39720b4e71049bd0030
> > likely use the same argument.
> >
> > In other cases, the project may use -Wa,-mrelax-relocations=no with
> > Clang (where they assume a not-too-old version), but need to work with
> > system ld (which may be old).
>
> This shouldn't happen with as and ld from the same binutils.

I agree.

> > > > doing configure work to check linker support.
> > >
> > > The TLS sequence from -fno-plt doesn't work for the older linker.
> > > The older linker support should be dropped for -fno-plt.
> > >
> > > > Now a user may use -fno-plt (Arch Linux, rustc, maybe Alpine) and run
> > > > into the aforementioned TLS problem.
> > > >
> > > > This 1-deletion-1-addition change can address this issue with no
> > > > maintenance burden on binutils side in my opinion,
> > > > so I made this patch.
> > > >
> > > > The linker design I described is true as well. Whether GOTPCRELX leads
> > > > to a GOT entry can be decided at relocation scanning time, before the
> > > > section layout is decided.
> > > > Users may make a conscious decision to use GOTPCREL to avoid potential
> > > > relocation overflow risk.
> > > >
> > > > GOTPCREL isn't really dead. It can be used with Intel LAM and tagged
> > > > global variables (with non-zero high address bits)
> > > > https://reviews.llvm.org/D111343
> > > > GOTPCREL instead of GOTPCRELX makes it clear an instruction
> > > > referencing the variable isn't supposed to be relaxed.
> > >
> > > The address of the local symbol, foo, in
> > >
> > > movq foo@GOTPCREL(%rip), %rax
> > >
> > > is assigned by the linker.  I am not sure how the tag is involved here.
> > > Besides, it is the call instruction here.
> >
> > This is an auxiliary argument. I wanted to emphasize that GOTPCREL
> > isn't dead and did not intend to use it with this call instruction.
> > If GOTPCRELX is used and the distance between the current location and
> > the symbol is larger than 2**31, this will trigger a relocation
> > overflow.
> >
> > This happens with tagged globals with non-zero high address bits.
>
> This sounds needing some linker changes to add tags to data variables.
> I am not sure if GOTPCREL alone is sufficient.
>
> > A linker can fix the problem by avoiding relaxation, increasing the
> > size of .got . This requires that it scans relocations more than once.
> > If GOTPCRELX is decided upfront whether it needs relaxation or not, on
> > an arch which doesn't use range extension thunks like x86, technically
> > relocations can just be scanned once.
> >
> > > > > > > > plt=no` and now relies on llvm-project to work around the GNU ld
> > > > > > > > compatibility issue.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > 宋方睿
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > H.J.
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > 宋方睿
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > H.J.
> > > >
> > > >
> > > >
> > > > --
> > > > 宋方睿
> > >
> > >
> > >
> > > --
> > > H.J.
> >
> >
> >
> > --
> > 宋方睿
>
>
>
> --
> H.J.



-- 
宋方睿

Re: [PATCH] ld: Allow R_X86_64_GOTPCREL for call *__tls_get_addr@GOTPCREL(%rip)

[H.J. Lu]

On Fri, Jan 6, 2023 at 3:52 PM Fangrui Song <maskray@google.com> wrote:
>
> On Fri, Jan 6, 2023 at 3:20 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> >
> > On Fri, Jan 6, 2023 at 3:02 PM Fangrui Song <maskray@google.com> wrote:
> > >
> > >  On Fri, Jan 6, 2023 at 2:42 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> > > >
> > > > On Fri, Jan 6, 2023 at 1:44 PM Fangrui Song <maskray@google.com> wrote:
> > > > >
> > > > > On Fri, Jan 6, 2023 at 1:27 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> > > > > >
> > > > > > On Fri, Jan 6, 2023 at 1:25 PM Fangrui Song <maskray@google.com> wrote:
> > > > > > >
> > > > > > >  On Fri, Jan 6, 2023 at 1:14 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> > > > > > > >
> > > > > > > > On Fri, Jan 6, 2023 at 10:48 AM Fangrui Song <maskray@google.com> wrote:
> > > > > > > > >
> > > > > > > > > On Fri, Jan 6, 2023 at 9:04 AM H.J. Lu <hjl.tools@gmail.com> wrote:
> > > > > > > > > >
> > > > > > > > > > On Thu, Jan 5, 2023 at 1:06 PM Fangrui Song via Binutils
> > > > > > > > > > <binutils@sourceware.org> wrote:
> > > > > > > > > > >
> > > > > > > > > > > _Thread_local int a;
> > > > > > > > > > > int main() { return a; }
> > > > > > > > > > >
> > > > > > > > > > > % gcc -fno-plt -fpic a.c -fuse-ld=bfd -Wa,-mrelax-relocations=no
> > > > > > > > > > > /usr/bin/ld.bfd: /tmp/ccSSBgrg.o: TLS transition from R_X86_64_TLSGD to R_X86_64_GOTTPOFF against `a' at 0xd in section `.text' failed
> > > > > > > > > > > /usr/bin/ld.bfd: failed to set dynamic section sizes: bad value
> > > > > > > > > > > collect2: error: ld returned 1 exit status
> > > > > > > > > > >
> > > > > > > > > > > This commit fixes the issue.
> > > > > > > > > > >
> > > > > > > > > > >     PR ld/24784
> > > > > > > > > > >     * bfd/elf64-x86-64.c (elf_x86_64_check_tls_transition): Allow
> > > > > > > > > > >       R_X86_64_GOTPCREL.
> > > > > > > > > > > ---
> > > > > > > > > > >  bfd/elf64-x86-64.c | 2 +-
> > > > > > > > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > > > > > > >
> > > > > > > > > > > diff --git a/bfd/elf64-x86-64.c b/bfd/elf64-x86-64.c
> > > > > > > > > > > index 914f82d0151..095fe2e0fe6 100644
> > > > > > > > > > > --- a/bfd/elf64-x86-64.c
> > > > > > > > > > > +++ b/bfd/elf64-x86-64.c
> > > > > > > > > > > @@ -1241,7 +1241,7 @@ elf_x86_64_check_tls_transition (bfd *abfd,
> > > > > > > > > > >           if (largepic)
> > > > > > > > > > >             return r_type == R_X86_64_PLTOFF64;
> > > > > > > > > > >           else if (indirect_call)
> > > > > > > > > > > -           return r_type == R_X86_64_GOTPCRELX;
> > > > > > > > > > > +           return (r_type == R_X86_64_GOTPCRELX || r_type == R_X86_64_GOTPCREL);
> > > > > > > > > > >           else
> > > > > > > > > > >             return (r_type == R_X86_64_PC32 || r_type == R_X86_64_PLT32);
> > > > > > > > > > >         }
> > > > > > > > > > > --
> > > > > > > > > > > 2.39.0.314.g84b9a713c41-goog
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Since the new TLS sequence was added after R_X86_64_GOTPCRELX was
> > > > > > > > > > required for call, R_X86_64_GOTPCREL should be invalid in this TLS sequence.
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > H.J.
> > > > > > > > >
> > > > > > > > > I have multiple arguments (albeit no single one is very strong) that
> > > > > > > > > this 1-deletion-1-addition change provides benefits for users (IMHO
> > > > > > > > > with no burden to binutils at all).
> > > > > > > > >
> > > > > > > > > Some projects may add -Wa,-mrelax-relocations=no to work around older
> > > > > > > > > GNU ld. Then the project's toolchain requirement may increase and no
> > > > > > > > > longer need to work around older GNU ld.
> > > > > > > > > But a distribution may for some reason use a global -fno-plt (e.g.
> > > > > > > > > Arch Linux) and then run into this TLS GD/LD->IE/LE optimization
> > > > > > > > > issue.
> > > > > > > > >
> > > > > > > > > rust src/ci/docker/host-x86_64/*musl/Dockerfile
> > > > > > > > > openjdk/jdk19u make/autoconf/flags-cflags.m4 (this file appears to be
> > > > > > > > > copied into quite a few projects)
> > > > > > > > > Linux kernel arch/x86/boot/compressed/Makefile (not a good example as
> > > > > > > > > it doesn't use TLS AFAICT)
> > > > > > > > >
> > > > > > > > > R_X86_64_GOTPCREL isn't purely usefull. It may help linker design: for
> > > > > > > > > R_X86_64_GOTPCRELX/R_X86_64_REX_GOTPCRELX, the linker can make a
> > > > > > > > > decision upfront whether a GOT entry is needed
> > > > > > > > > (this affects the size of .got, which may affect section layout and
> > > > > > > > > whether other relocations may overflow).
> > > > > > > > > This may increase risk of 32-bit relocation overflow.
> > > > > > > > > R_X86_64_GOTPCREL can mitigate the risk while being aware to the user.
> > > > > > > > >
> > > > > > > > > rustc somehow disables x86 relaxed relocations and defaults to `-Z
> > > > > > > >
> > > > > > > > Why is that?
> > > > > > >
> > > > > > > It's assuredly a rust's problem and I am trying to fix that in
> > > > > > > https://github.com/rust-lang/rust/pull/106511
> > > > > > >
> > > > > > > The  -Wa,-mrelax-relocations=no problem may affect more packages.
> > > > > >
> > > > > > -mrelax-relocations=no should be a workaround for the older linker.   It
> > > > > > shouldn't be used with the current linker.
> > > > >
> > > > > A project may choose to work with many linker versions.
> > > > > For simplicity, before it decides to drop compatibility with GNU
> > > > > ld<2.26 (AIUI GOTPCRELX was supported in 2.26),
> > > > > it may unconditionally add -Wa,-mrelax-relocations=no, instead of
> > > >
> > > > -mrelax-relocations=no is only supported with the newer binutils.
> > >
> > > The relocatable object file producer and the consumer may be on
> > > different machines and use different binutils versions.
> > > https://github.com/rust-lang/rust/commit/305aca86f9d8d132650b495f610f9abe5239fec6
> > > added -Wa,-mrelax-relocations=no so that the relocatable object files
> > > can be used on a user machine with an old ld.
> >
> > But -fno-plt may not work with the old linker.   For this matter,
> > -Wa,-mrelax-relocations=no doesn't work with ld today.  When
> > -Wa,-mrelax-relocations=no is used, no features from newer linkers
> > can be used.
>
> A project may add -Wa,-mrelax-relocations=no so that its prebuilt
> relocatable object files can be linked on a machine with old ld.
>
> A distribution (like Arch Linux and rust) using new ld may decide to
> use -fno-plt globally. If they don't strip or override the project
> -Wa,-mrelax-relocations=no,
> they may run into the -fpic -fno-plt -Wa,-mrelax-relocations=no incompatibility.

-Wa,-mrelax-relocations=no should be removed when -fno-plt is added.

> In the GCC/gas model, GCC doesn't know whether its emitted assembly
> will be used with -mrelax-relocations=no.
> GCC just emits the -fno-plt form of TLS GD/LD code sequence. If the
> assembly is fed into gas with -mrelax-relocations=no, the output will
> be broken with current ld.
>
> I have tested some TLS examples and this simple patch work. One can
> argue that GNU ld either suppresses GD/LD=>IE/LE optimization or
> support this old relocation type.
> It appears that supporting the old relocation type is the simplest approach.
>
> > > https://github.com/IHaskell/IHaskell/issues/636 and
> > > https://github.com/dcos/dcos/commit/facda25019e07051f501b39720b4e71049bd0030
> > > likely use the same argument.
> > >
> > > In other cases, the project may use -Wa,-mrelax-relocations=no with
> > > Clang (where they assume a not-too-old version), but need to work with
> > > system ld (which may be old).
> >
> > This shouldn't happen with as and ld from the same binutils.
>
> I agree.
>
> > > > > doing configure work to check linker support.
> > > >
> > > > The TLS sequence from -fno-plt doesn't work for the older linker.
> > > > The older linker support should be dropped for -fno-plt.
> > > >
> > > > > Now a user may use -fno-plt (Arch Linux, rustc, maybe Alpine) and run
> > > > > into the aforementioned TLS problem.
> > > > >
> > > > > This 1-deletion-1-addition change can address this issue with no
> > > > > maintenance burden on binutils side in my opinion,
> > > > > so I made this patch.
> > > > >
> > > > > The linker design I described is true as well. Whether GOTPCRELX leads
> > > > > to a GOT entry can be decided at relocation scanning time, before the
> > > > > section layout is decided.
> > > > > Users may make a conscious decision to use GOTPCREL to avoid potential
> > > > > relocation overflow risk.
> > > > >
> > > > > GOTPCREL isn't really dead. It can be used with Intel LAM and tagged
> > > > > global variables (with non-zero high address bits)
> > > > > https://reviews.llvm.org/D111343
> > > > > GOTPCREL instead of GOTPCRELX makes it clear an instruction
> > > > > referencing the variable isn't supposed to be relaxed.
> > > >
> > > > The address of the local symbol, foo, in
> > > >
> > > > movq foo@GOTPCREL(%rip), %rax
> > > >
> > > > is assigned by the linker.  I am not sure how the tag is involved here.
> > > > Besides, it is the call instruction here.
> > >
> > > This is an auxiliary argument. I wanted to emphasize that GOTPCREL
> > > isn't dead and did not intend to use it with this call instruction.
> > > If GOTPCRELX is used and the distance between the current location and
> > > the symbol is larger than 2**31, this will trigger a relocation
> > > overflow.
> > >
> > > This happens with tagged globals with non-zero high address bits.
> >
> > This sounds needing some linker changes to add tags to data variables.
> > I am not sure if GOTPCREL alone is sufficient.
> >
> > > A linker can fix the problem by avoiding relaxation, increasing the
> > > size of .got . This requires that it scans relocations more than once.
> > > If GOTPCRELX is decided upfront whether it needs relaxation or not, on
> > > an arch which doesn't use range extension thunks like x86, technically
> > > relocations can just be scanned once.
> > >
> > > > > > > > > plt=no` and now relies on llvm-project to work around the GNU ld
> > > > > > > > > compatibility issue.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > 宋方睿
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > H.J.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > 宋方睿
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > H.J.
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > 宋方睿
> > > >
> > > >
> > > >
> > > > --
> > > > H.J.
> > >
> > >
> > >
> > > --
> > > 宋方睿
> >
> >
> >
> > --
> > H.J.
>
>
>
> --
> 宋方睿



-- 
H.J.

Re: [PATCH] ld: Allow R_X86_64_GOTPCREL for call *__tls_get_addr@GOTPCREL(%rip)

[Jan Beulich]

On 06.01.2023 18:03, H.J. Lu via Binutils wrote:
> On Thu, Jan 5, 2023 at 1:06 PM Fangrui Song via Binutils
> <binutils@sourceware.org> wrote:
>>
>> _Thread_local int a;
>> int main() { return a; }
>>
>> % gcc -fno-plt -fpic a.c -fuse-ld=bfd -Wa,-mrelax-relocations=no
>> /usr/bin/ld.bfd: /tmp/ccSSBgrg.o: TLS transition from R_X86_64_TLSGD to R_X86_64_GOTTPOFF against `a' at 0xd in section `.text' failed
>> /usr/bin/ld.bfd: failed to set dynamic section sizes: bad value
>> collect2: error: ld returned 1 exit status
>>
>> This commit fixes the issue.
>>
>>     PR ld/24784
>>     * bfd/elf64-x86-64.c (elf_x86_64_check_tls_transition): Allow
>>       R_X86_64_GOTPCREL.
>> ---
>>  bfd/elf64-x86-64.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/bfd/elf64-x86-64.c b/bfd/elf64-x86-64.c
>> index 914f82d0151..095fe2e0fe6 100644
>> --- a/bfd/elf64-x86-64.c
>> +++ b/bfd/elf64-x86-64.c
>> @@ -1241,7 +1241,7 @@ elf_x86_64_check_tls_transition (bfd *abfd,
>>           if (largepic)
>>             return r_type == R_X86_64_PLTOFF64;
>>           else if (indirect_call)
>> -           return r_type == R_X86_64_GOTPCRELX;
>> +           return (r_type == R_X86_64_GOTPCRELX || r_type == R_X86_64_GOTPCREL);
>>           else
>>             return (r_type == R_X86_64_PC32 || r_type == R_X86_64_PLT32);
>>         }
>> --
>> 2.39.0.314.g84b9a713c41-goog
>>
> 
> Since the new TLS sequence was added after R_X86_64_GOTPCRELX was
> required for call, R_X86_64_GOTPCREL should be invalid in this TLS sequence.

While this may well be, would you mind pointing out (more to Fangrui than to
me) what bad his proposed change would do?

Jan

Re: [PATCH] ld: Allow R_X86_64_GOTPCREL for call *__tls_get_addr@GOTPCREL(%rip)

[H.J. Lu]

On Mon, Jan 9, 2023 at 12:15 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 06.01.2023 18:03, H.J. Lu via Binutils wrote:
> > On Thu, Jan 5, 2023 at 1:06 PM Fangrui Song via Binutils
> > <binutils@sourceware.org> wrote:
> >>
> >> _Thread_local int a;
> >> int main() { return a; }
> >>
> >> % gcc -fno-plt -fpic a.c -fuse-ld=bfd -Wa,-mrelax-relocations=no
> >> /usr/bin/ld.bfd: /tmp/ccSSBgrg.o: TLS transition from R_X86_64_TLSGD to R_X86_64_GOTTPOFF against `a' at 0xd in section `.text' failed
> >> /usr/bin/ld.bfd: failed to set dynamic section sizes: bad value
> >> collect2: error: ld returned 1 exit status
> >>
> >> This commit fixes the issue.
> >>
> >>     PR ld/24784
> >>     * bfd/elf64-x86-64.c (elf_x86_64_check_tls_transition): Allow
> >>       R_X86_64_GOTPCREL.
> >> ---
> >>  bfd/elf64-x86-64.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/bfd/elf64-x86-64.c b/bfd/elf64-x86-64.c
> >> index 914f82d0151..095fe2e0fe6 100644
> >> --- a/bfd/elf64-x86-64.c
> >> +++ b/bfd/elf64-x86-64.c
> >> @@ -1241,7 +1241,7 @@ elf_x86_64_check_tls_transition (bfd *abfd,
> >>           if (largepic)
> >>             return r_type == R_X86_64_PLTOFF64;
> >>           else if (indirect_call)
> >> -           return r_type == R_X86_64_GOTPCRELX;
> >> +           return (r_type == R_X86_64_GOTPCRELX || r_type == R_X86_64_GOTPCREL);
> >>           else
> >>             return (r_type == R_X86_64_PC32 || r_type == R_X86_64_PLT32);
> >>         }
> >> --
> >> 2.39.0.314.g84b9a713c41-goog
> >>
> >
> > Since the new TLS sequence was added after R_X86_64_GOTPCRELX was
> > required for call, R_X86_64_GOTPCREL should be invalid in this TLS sequence.
>
> While this may well be, would you mind pointing out (more to Fangrui than to
> me) what bad his proposed change would do?
>
> Jan

The problem is caused by the combination of -fno-plt and
-Wa,-mrelax-relocations=no.
-Wa,-mrelax-relocations=no was added to generate object files to be
consumed by the
older linkers.   On the other hand, -fno-plt requires newer linkers.
As the result,
 -fno-plt -Wa,-mrelax-relocations=no generates object files which
aren't compatible
with neither older linkers nor newer linkers.
-Wa,-mrelax-relocations shouldn't be used
together with -fno-plt.

-- 
H.J.

Re: [PATCH] ld: Allow R_X86_64_GOTPCREL for call *__tls_get_addr@GOTPCREL(%rip)

[Jan Beulich]

On 09.01.2023 22:14, H.J. Lu wrote:
> On Mon, Jan 9, 2023 at 12:15 AM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 06.01.2023 18:03, H.J. Lu via Binutils wrote:
>>> On Thu, Jan 5, 2023 at 1:06 PM Fangrui Song via Binutils
>>> <binutils@sourceware.org> wrote:
>>>>
>>>> _Thread_local int a;
>>>> int main() { return a; }
>>>>
>>>> % gcc -fno-plt -fpic a.c -fuse-ld=bfd -Wa,-mrelax-relocations=no
>>>> /usr/bin/ld.bfd: /tmp/ccSSBgrg.o: TLS transition from R_X86_64_TLSGD to R_X86_64_GOTTPOFF against `a' at 0xd in section `.text' failed
>>>> /usr/bin/ld.bfd: failed to set dynamic section sizes: bad value
>>>> collect2: error: ld returned 1 exit status
>>>>
>>>> This commit fixes the issue.
>>>>
>>>>     PR ld/24784
>>>>     * bfd/elf64-x86-64.c (elf_x86_64_check_tls_transition): Allow
>>>>       R_X86_64_GOTPCREL.
>>>> ---
>>>>  bfd/elf64-x86-64.c | 2 +-
>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/bfd/elf64-x86-64.c b/bfd/elf64-x86-64.c
>>>> index 914f82d0151..095fe2e0fe6 100644
>>>> --- a/bfd/elf64-x86-64.c
>>>> +++ b/bfd/elf64-x86-64.c
>>>> @@ -1241,7 +1241,7 @@ elf_x86_64_check_tls_transition (bfd *abfd,
>>>>           if (largepic)
>>>>             return r_type == R_X86_64_PLTOFF64;
>>>>           else if (indirect_call)
>>>> -           return r_type == R_X86_64_GOTPCRELX;
>>>> +           return (r_type == R_X86_64_GOTPCRELX || r_type == R_X86_64_GOTPCREL);
>>>>           else
>>>>             return (r_type == R_X86_64_PC32 || r_type == R_X86_64_PLT32);
>>>>         }
>>>> --
>>>> 2.39.0.314.g84b9a713c41-goog
>>>>
>>>
>>> Since the new TLS sequence was added after R_X86_64_GOTPCRELX was
>>> required for call, R_X86_64_GOTPCREL should be invalid in this TLS sequence.
>>
>> While this may well be, would you mind pointing out (more to Fangrui than to
>> me) what bad his proposed change would do?
> 
> The problem is caused by the combination of -fno-plt and
> -Wa,-mrelax-relocations=no.
> -Wa,-mrelax-relocations=no was added to generate object files to be
> consumed by the
> older linkers.   On the other hand, -fno-plt requires newer linkers.
> As the result,
>  -fno-plt -Wa,-mrelax-relocations=no generates object files which
> aren't compatible
> with neither older linkers nor newer linkers.
> -Wa,-mrelax-relocations shouldn't be used
> together with -fno-plt.

Imo use of such option combinations should either be disallowed (warned
about at the very least) or produce sensible output. I guess only the
latter would help Fangrui ...

Jan

Re: [PATCH] ld: Allow R_X86_64_GOTPCREL for call *__tls_get_addr@GOTPCREL(%rip)

[H.J. Lu]

On Tue, Jan 10, 2023 at 1:16 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 09.01.2023 22:14, H.J. Lu wrote:
> > On Mon, Jan 9, 2023 at 12:15 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>
> >> On 06.01.2023 18:03, H.J. Lu via Binutils wrote:
> >>> On Thu, Jan 5, 2023 at 1:06 PM Fangrui Song via Binutils
> >>> <binutils@sourceware.org> wrote:
> >>>>
> >>>> _Thread_local int a;
> >>>> int main() { return a; }
> >>>>
> >>>> % gcc -fno-plt -fpic a.c -fuse-ld=bfd -Wa,-mrelax-relocations=no
> >>>> /usr/bin/ld.bfd: /tmp/ccSSBgrg.o: TLS transition from R_X86_64_TLSGD to R_X86_64_GOTTPOFF against `a' at 0xd in section `.text' failed
> >>>> /usr/bin/ld.bfd: failed to set dynamic section sizes: bad value
> >>>> collect2: error: ld returned 1 exit status
> >>>>
> >>>> This commit fixes the issue.
> >>>>
> >>>>     PR ld/24784
> >>>>     * bfd/elf64-x86-64.c (elf_x86_64_check_tls_transition): Allow
> >>>>       R_X86_64_GOTPCREL.
> >>>> ---
> >>>>  bfd/elf64-x86-64.c | 2 +-
> >>>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/bfd/elf64-x86-64.c b/bfd/elf64-x86-64.c
> >>>> index 914f82d0151..095fe2e0fe6 100644
> >>>> --- a/bfd/elf64-x86-64.c
> >>>> +++ b/bfd/elf64-x86-64.c
> >>>> @@ -1241,7 +1241,7 @@ elf_x86_64_check_tls_transition (bfd *abfd,
> >>>>           if (largepic)
> >>>>             return r_type == R_X86_64_PLTOFF64;
> >>>>           else if (indirect_call)
> >>>> -           return r_type == R_X86_64_GOTPCRELX;
> >>>> +           return (r_type == R_X86_64_GOTPCRELX || r_type == R_X86_64_GOTPCREL);
> >>>>           else
> >>>>             return (r_type == R_X86_64_PC32 || r_type == R_X86_64_PLT32);
> >>>>         }
> >>>> --
> >>>> 2.39.0.314.g84b9a713c41-goog
> >>>>
> >>>
> >>> Since the new TLS sequence was added after R_X86_64_GOTPCRELX was
> >>> required for call, R_X86_64_GOTPCREL should be invalid in this TLS sequence.
> >>
> >> While this may well be, would you mind pointing out (more to Fangrui than to
> >> me) what bad his proposed change would do?
> >
> > The problem is caused by the combination of -fno-plt and
> > -Wa,-mrelax-relocations=no.
> > -Wa,-mrelax-relocations=no was added to generate object files to be
> > consumed by the
> > older linkers.   On the other hand, -fno-plt requires newer linkers.
> > As the result,
> >  -fno-plt -Wa,-mrelax-relocations=no generates object files which
> > aren't compatible
> > with neither older linkers nor newer linkers.
> > -Wa,-mrelax-relocations shouldn't be used
> > together with -fno-plt.
>
> Imo use of such option combinations should either be disallowed (warned
> about at the very least) or produce sensible output. I guess only the
> latter would help Fangrui ...
>

This isn't a supported combination.  I believe -Wa,-mrelax-relocations=no
should be removed.

-- 
H.J.

Re: [PATCH] ld: Allow R_X86_64_GOTPCREL for call *__tls_get_addr@GOTPCREL(%rip)

[Fangrui Song]

On Tue, Jan 10, 2023 at 12:40 PM H.J. Lu <hjl.tools@gmail.com> wrote:
>
> On Tue, Jan 10, 2023 at 1:16 AM Jan Beulich <jbeulich@suse.com> wrote:
> >
> > On 09.01.2023 22:14, H.J. Lu wrote:
> > > On Mon, Jan 9, 2023 at 12:15 AM Jan Beulich <jbeulich@suse.com> wrote:
> > >>
> > >> On 06.01.2023 18:03, H.J. Lu via Binutils wrote:
> > >>> On Thu, Jan 5, 2023 at 1:06 PM Fangrui Song via Binutils
> > >>> <binutils@sourceware.org> wrote:
> > >>>>
> > >>>> _Thread_local int a;
> > >>>> int main() { return a; }
> > >>>>
> > >>>> % gcc -fno-plt -fpic a.c -fuse-ld=bfd -Wa,-mrelax-relocations=no
> > >>>> /usr/bin/ld.bfd: /tmp/ccSSBgrg.o: TLS transition from R_X86_64_TLSGD to R_X86_64_GOTTPOFF against `a' at 0xd in section `.text' failed
> > >>>> /usr/bin/ld.bfd: failed to set dynamic section sizes: bad value
> > >>>> collect2: error: ld returned 1 exit status
> > >>>>
> > >>>> This commit fixes the issue.
> > >>>>
> > >>>>     PR ld/24784
> > >>>>     * bfd/elf64-x86-64.c (elf_x86_64_check_tls_transition): Allow
> > >>>>       R_X86_64_GOTPCREL.
> > >>>> ---
> > >>>>  bfd/elf64-x86-64.c | 2 +-
> > >>>>  1 file changed, 1 insertion(+), 1 deletion(-)
> > >>>>
> > >>>> diff --git a/bfd/elf64-x86-64.c b/bfd/elf64-x86-64.c
> > >>>> index 914f82d0151..095fe2e0fe6 100644
> > >>>> --- a/bfd/elf64-x86-64.c
> > >>>> +++ b/bfd/elf64-x86-64.c
> > >>>> @@ -1241,7 +1241,7 @@ elf_x86_64_check_tls_transition (bfd *abfd,
> > >>>>           if (largepic)
> > >>>>             return r_type == R_X86_64_PLTOFF64;
> > >>>>           else if (indirect_call)
> > >>>> -           return r_type == R_X86_64_GOTPCRELX;
> > >>>> +           return (r_type == R_X86_64_GOTPCRELX || r_type == R_X86_64_GOTPCREL);
> > >>>>           else
> > >>>>             return (r_type == R_X86_64_PC32 || r_type == R_X86_64_PLT32);
> > >>>>         }
> > >>>> --
> > >>>> 2.39.0.314.g84b9a713c41-goog
> > >>>>
> > >>>
> > >>> Since the new TLS sequence was added after R_X86_64_GOTPCRELX was
> > >>> required for call, R_X86_64_GOTPCREL should be invalid in this TLS sequence.
> > >>
> > >> While this may well be, would you mind pointing out (more to Fangrui than to
> > >> me) what bad his proposed change would do?
> > >
> > > The problem is caused by the combination of -fno-plt and
> > > -Wa,-mrelax-relocations=no.
> > > -Wa,-mrelax-relocations=no was added to generate object files to be
> > > consumed by the
> > > older linkers.   On the other hand, -fno-plt requires newer linkers.
> > > As the result,
> > >  -fno-plt -Wa,-mrelax-relocations=no generates object files which
> > > aren't compatible
> > > with neither older linkers nor newer linkers.
> > > -Wa,-mrelax-relocations shouldn't be used
> > > together with -fno-plt.
> >
> > Imo use of such option combinations should either be disallowed (warned
> > about at the very least) or produce sensible output. I guess only the
> > latter would help Fangrui ...
> >
>
> This isn't a supported combination.  I believe -Wa,-mrelax-relocations=no
> should be removed.
>
> --
> H.J.

Removing -Wa,-mrelax-relocations=no implies that R_X86_64_GOTPCREL is
completely useless and -Wl,--no-relax is not useful for x86.

As my earliest replies mentioned, a relocation type indication no
relaxation is useful in some cases: hwasan (Intel LAM) references to
global variables, one-pass relocation scanning design in a linker,
even if we disregard the relocatable-file-producer with
old-linker-consumer compatibility scenarios.

If the linker can decide upfront whether GOTPCREL{,X} needs a GOT
entry, the relocation scanning pass be one-pass and be completely
moved before synthetic sections (.got, .plt, .got.plt, etc), instead
of interleaving relocation scanning, synthetic section size decision,
and section layout.

Re: [PATCH] ld: Allow R_X86_64_GOTPCREL for call *__tls_get_addr@GOTPCREL(%rip)

[Jan Beulich]

On 10.01.2023 22:02, Fangrui Song wrote:
> On Tue, Jan 10, 2023 at 12:40 PM H.J. Lu <hjl.tools@gmail.com> wrote:
>> On Tue, Jan 10, 2023 at 1:16 AM Jan Beulich <jbeulich@suse.com> wrote:
>>> On 09.01.2023 22:14, H.J. Lu wrote:
>>>> On Mon, Jan 9, 2023 at 12:15 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>> On 06.01.2023 18:03, H.J. Lu via Binutils wrote:
>>>>>> On Thu, Jan 5, 2023 at 1:06 PM Fangrui Song via Binutils
>>>>>> <binutils@sourceware.org> wrote:
>>>>>>>
>>>>>>> _Thread_local int a;
>>>>>>> int main() { return a; }
>>>>>>>
>>>>>>> % gcc -fno-plt -fpic a.c -fuse-ld=bfd -Wa,-mrelax-relocations=no
>>>>>>> /usr/bin/ld.bfd: /tmp/ccSSBgrg.o: TLS transition from R_X86_64_TLSGD to R_X86_64_GOTTPOFF against `a' at 0xd in section `.text' failed
>>>>>>> /usr/bin/ld.bfd: failed to set dynamic section sizes: bad value
>>>>>>> collect2: error: ld returned 1 exit status
>>>>>>>
>>>>>>> This commit fixes the issue.
>>>>>>>
>>>>>>>     PR ld/24784
>>>>>>>     * bfd/elf64-x86-64.c (elf_x86_64_check_tls_transition): Allow
>>>>>>>       R_X86_64_GOTPCREL.
>>>>>>> ---
>>>>>>>  bfd/elf64-x86-64.c | 2 +-
>>>>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>>
>>>>>>> diff --git a/bfd/elf64-x86-64.c b/bfd/elf64-x86-64.c
>>>>>>> index 914f82d0151..095fe2e0fe6 100644
>>>>>>> --- a/bfd/elf64-x86-64.c
>>>>>>> +++ b/bfd/elf64-x86-64.c
>>>>>>> @@ -1241,7 +1241,7 @@ elf_x86_64_check_tls_transition (bfd *abfd,
>>>>>>>           if (largepic)
>>>>>>>             return r_type == R_X86_64_PLTOFF64;
>>>>>>>           else if (indirect_call)
>>>>>>> -           return r_type == R_X86_64_GOTPCRELX;
>>>>>>> +           return (r_type == R_X86_64_GOTPCRELX || r_type == R_X86_64_GOTPCREL);
>>>>>>>           else
>>>>>>>             return (r_type == R_X86_64_PC32 || r_type == R_X86_64_PLT32);
>>>>>>>         }
>>>>>>> --
>>>>>>> 2.39.0.314.g84b9a713c41-goog
>>>>>>>
>>>>>>
>>>>>> Since the new TLS sequence was added after R_X86_64_GOTPCRELX was
>>>>>> required for call, R_X86_64_GOTPCREL should be invalid in this TLS sequence.
>>>>>
>>>>> While this may well be, would you mind pointing out (more to Fangrui than to
>>>>> me) what bad his proposed change would do?
>>>>
>>>> The problem is caused by the combination of -fno-plt and
>>>> -Wa,-mrelax-relocations=no.
>>>> -Wa,-mrelax-relocations=no was added to generate object files to be
>>>> consumed by the
>>>> older linkers.   On the other hand, -fno-plt requires newer linkers.
>>>> As the result,
>>>>  -fno-plt -Wa,-mrelax-relocations=no generates object files which
>>>> aren't compatible
>>>> with neither older linkers nor newer linkers.
>>>> -Wa,-mrelax-relocations shouldn't be used
>>>> together with -fno-plt.
>>>
>>> Imo use of such option combinations should either be disallowed (warned
>>> about at the very least) or produce sensible output. I guess only the
>>> latter would help Fangrui ...
>>>
>>
>> This isn't a supported combination.  I believe -Wa,-mrelax-relocations=no
>> should be removed.
> 
> Removing -Wa,-mrelax-relocations=no implies that R_X86_64_GOTPCREL is
> completely useless and -Wl,--no-relax is not useful for x86.
> 
> As my earliest replies mentioned, a relocation type indication no
> relaxation is useful in some cases: hwasan (Intel LAM) references to
> global variables, one-pass relocation scanning design in a linker,
> even if we disregard the relocatable-file-producer with
> old-linker-consumer compatibility scenarios.
> 
> If the linker can decide upfront whether GOTPCREL{,X} needs a GOT
> entry, the relocation scanning pass be one-pass and be completely
> moved before synthetic sections (.got, .plt, .got.plt, etc), instead
> of interleaving relocation scanning, synthetic section size decision,
> and section layout.

I agree with Fangrui's view here. I further think that the original change
was (once again) overly limiting applicability (why ADC and SBB but not
e.g. ADCX and ADOX) or doing things in an overly relaxed fashion (the
subsequently addressed 16-bit operand size issue being just one aspect;
I wonder whether 32-bit vs 64-bit operand size is actually handled
correctly there in 64-bit and/or x32 mode).

Jan

Re: [PATCH] ld: Allow R_X86_64_GOTPCREL for call *__tls_get_addr@GOTPCREL(%rip)

[Jan Beulich]

On 10.01.2023 21:39, H.J. Lu wrote:
> On Tue, Jan 10, 2023 at 1:16 AM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 09.01.2023 22:14, H.J. Lu wrote:
>>> On Mon, Jan 9, 2023 at 12:15 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>
>>>> On 06.01.2023 18:03, H.J. Lu via Binutils wrote:
>>>>> On Thu, Jan 5, 2023 at 1:06 PM Fangrui Song via Binutils
>>>>> <binutils@sourceware.org> wrote:
>>>>>>
>>>>>> _Thread_local int a;
>>>>>> int main() { return a; }
>>>>>>
>>>>>> % gcc -fno-plt -fpic a.c -fuse-ld=bfd -Wa,-mrelax-relocations=no
>>>>>> /usr/bin/ld.bfd: /tmp/ccSSBgrg.o: TLS transition from R_X86_64_TLSGD to R_X86_64_GOTTPOFF against `a' at 0xd in section `.text' failed
>>>>>> /usr/bin/ld.bfd: failed to set dynamic section sizes: bad value
>>>>>> collect2: error: ld returned 1 exit status
>>>>>>
>>>>>> This commit fixes the issue.
>>>>>>
>>>>>>     PR ld/24784
>>>>>>     * bfd/elf64-x86-64.c (elf_x86_64_check_tls_transition): Allow
>>>>>>       R_X86_64_GOTPCREL.
>>>>>> ---
>>>>>>  bfd/elf64-x86-64.c | 2 +-
>>>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/bfd/elf64-x86-64.c b/bfd/elf64-x86-64.c
>>>>>> index 914f82d0151..095fe2e0fe6 100644
>>>>>> --- a/bfd/elf64-x86-64.c
>>>>>> +++ b/bfd/elf64-x86-64.c
>>>>>> @@ -1241,7 +1241,7 @@ elf_x86_64_check_tls_transition (bfd *abfd,
>>>>>>           if (largepic)
>>>>>>             return r_type == R_X86_64_PLTOFF64;
>>>>>>           else if (indirect_call)
>>>>>> -           return r_type == R_X86_64_GOTPCRELX;
>>>>>> +           return (r_type == R_X86_64_GOTPCRELX || r_type == R_X86_64_GOTPCREL);
>>>>>>           else
>>>>>>             return (r_type == R_X86_64_PC32 || r_type == R_X86_64_PLT32);
>>>>>>         }
>>>>>> --
>>>>>> 2.39.0.314.g84b9a713c41-goog
>>>>>>
>>>>>
>>>>> Since the new TLS sequence was added after R_X86_64_GOTPCRELX was
>>>>> required for call, R_X86_64_GOTPCREL should be invalid in this TLS sequence.
>>>>
>>>> While this may well be, would you mind pointing out (more to Fangrui than to
>>>> me) what bad his proposed change would do?
>>>
>>> The problem is caused by the combination of -fno-plt and
>>> -Wa,-mrelax-relocations=no.
>>> -Wa,-mrelax-relocations=no was added to generate object files to be
>>> consumed by the
>>> older linkers.   On the other hand, -fno-plt requires newer linkers.
>>> As the result,
>>>  -fno-plt -Wa,-mrelax-relocations=no generates object files which
>>> aren't compatible
>>> with neither older linkers nor newer linkers.
>>> -Wa,-mrelax-relocations shouldn't be used
>>> together with -fno-plt.
>>
>> Imo use of such option combinations should either be disallowed (warned
>> about at the very least) or produce sensible output. I guess only the
>> latter would help Fangrui ...
>>
> 
> This isn't a supported combination.  I believe -Wa,-mrelax-relocations=no
> should be removed.

But the reason it was introduced (commit 0cb4071ef9e1) hasn't disappeared.

Jan

Re: [PATCH] ld: Allow R_X86_64_GOTPCREL for call *__tls_get_addr@GOTPCREL(%rip)

[Jan Beulich]

On 05.01.2023 22:05, Fangrui Song via Binutils wrote:
> _Thread_local int a;
> int main() { return a; }
> 
> % gcc -fno-plt -fpic a.c -fuse-ld=bfd -Wa,-mrelax-relocations=no
> /usr/bin/ld.bfd: /tmp/ccSSBgrg.o: TLS transition from R_X86_64_TLSGD to R_X86_64_GOTTPOFF against `a' at 0xd in section `.text' failed
> /usr/bin/ld.bfd: failed to set dynamic section sizes: bad value
> collect2: error: ld returned 1 exit status
> 
> This commit fixes the issue.

The discussion with H.J. looks to have died out, without a clear result.
May I suggest the following (also for the other, 32-bit patch): You
extend the description to address H.J.'s concerns verbally, and unless
he comes forward pointing actual flaws in here, I'd then intend to
approve the changes.

Jan

>     PR ld/24784
>     * bfd/elf64-x86-64.c (elf_x86_64_check_tls_transition): Allow
>       R_X86_64_GOTPCREL.
> ---
>  bfd/elf64-x86-64.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/bfd/elf64-x86-64.c b/bfd/elf64-x86-64.c
> index 914f82d0151..095fe2e0fe6 100644
> --- a/bfd/elf64-x86-64.c
> +++ b/bfd/elf64-x86-64.c
> @@ -1241,7 +1241,7 @@ elf_x86_64_check_tls_transition (bfd *abfd,
>  	  if (largepic)
>  	    return r_type == R_X86_64_PLTOFF64;
>  	  else if (indirect_call)
> -	    return r_type == R_X86_64_GOTPCRELX;
> +	    return (r_type == R_X86_64_GOTPCRELX || r_type == R_X86_64_GOTPCREL);
>  	  else
>  	    return (r_type == R_X86_64_PC32 || r_type == R_X86_64_PLT32);
>  	}

[PATCH v2] ld: Allow R_X86_64_GOTPCREL for call *__tls_get_addr@GOTPCREL(%rip)

[Fangrui Song]

On 2023-03-02, Jan Beulich wrote:
>On 05.01.2023 22:05, Fangrui Song via Binutils wrote:
>> _Thread_local int a;
>> int main() { return a; }
>>
>> % gcc -fno-plt -fpic a.c -fuse-ld=bfd -Wa,-mrelax-relocations=no
>> /usr/bin/ld.bfd: /tmp/ccSSBgrg.o: TLS transition from R_X86_64_TLSGD to R_X86_64_GOTTPOFF against `a' at 0xd in section `.text' failed
>> /usr/bin/ld.bfd: failed to set dynamic section sizes: bad value
>> collect2: error: ld returned 1 exit status
>>
>> This commit fixes the issue.
>
>The discussion with H.J. looks to have died out, without a clear result.
>May I suggest the following (also for the other, 32-bit patch): You
>extend the description to address H.J.'s concerns verbally, and unless
>he comes forward pointing actual flaws in here, I'd then intend to
>approve the changes.
>
>Jan
>
>>     PR ld/24784
>>     * bfd/elf64-x86-64.c (elf_x86_64_check_tls_transition): Allow
>>       R_X86_64_GOTPCREL.
>> ---
>>  bfd/elf64-x86-64.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/bfd/elf64-x86-64.c b/bfd/elf64-x86-64.c
>> index 914f82d0151..095fe2e0fe6 100644
>> --- a/bfd/elf64-x86-64.c
>> +++ b/bfd/elf64-x86-64.c
>> @@ -1241,7 +1241,7 @@ elf_x86_64_check_tls_transition (bfd *abfd,
>>  	  if (largepic)
>>  	    return r_type == R_X86_64_PLTOFF64;
>>  	  else if (indirect_call)
>> -	    return r_type == R_X86_64_GOTPCRELX;
>> +	    return (r_type == R_X86_64_GOTPCRELX || r_type == R_X86_64_GOTPCREL);
>>  	  else
>>  	    return (r_type == R_X86_64_PC32 || r_type == R_X86_64_PLT32);
>>  	}
>

Thank you!  Here is PATCH v2 with an updated description but no code
change:


 From a8df373aec097dcdabe46717dd95cdd9b16ef7d7 Mon Sep 17 00:00:00 2001
From: Fangrui Song <maskray@google.com>
Date: Thu, 5 Jan 2023 12:45:27 -0800
Subject: [PATCH v2] ld: Allow R_X86_64_GOTPCREL for call
  *__tls_get_addr@GOTPCREL(%rip)

_Thread_local int a;
int main() { return a; }

% gcc -fno-plt -fpic a.c -fuse-ld=bfd -Wa,-mrelax-relocations=no
/usr/bin/ld.bfd: /tmp/ccSSBgrg.o: TLS transition from R_X86_64_TLSGD to R_X86_64_GOTTPOFF against `a' at 0xd in section `.text' failed
/usr/bin/ld.bfd: failed to set dynamic section sizes: bad value
collect2: error: ld returned 1 exit status

This commit fixes the issue.

There is an argument that the -fno-plt TLS sequence was added after
R_X86_64_GOTPCRELX was required for call, so R_X86_64_GOTPCREL was
intended to be unsupported.

Unfortunately this standpoint has caused interop difficulty: some
projects specify -mrelax-relocations=no to build relocatable object
files compatible with older linkers (e.g.
https://github.com/IHaskell/IHaskell/issues/636) or do so by accident
(e.g. https://github.com/rust-lang/rust/pull/106511 not addressed as of
today).  Many uses have not been cleaned up in practice, and compiling
with -fno-plt will lead to the `TLS transition from R_X86_64_TLSGD ...`
error which is hard to reason about.

There is another argument which may be weaker but relevant to the
necessity of -mrelax-relocations=no: HWAddressSanitizer x86-64 will
likely need some assembler support to disable relaxation.  Without the
support and if the compiler needs to support many gas versions, the
simplest solutation would be to use -Wa,-mrelax-relocations=no.

     PR ld/24784
     * bfd/elf64-x86-64.c (elf_x86_64_check_tls_transition): Allow
       R_X86_64_GOTPCREL.
---
  bfd/elf64-x86-64.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bfd/elf64-x86-64.c b/bfd/elf64-x86-64.c
index 0aa9af5d8fc..dd987ee011b 100644
--- a/bfd/elf64-x86-64.c
+++ b/bfd/elf64-x86-64.c
@@ -1253,7 +1253,7 @@ elf_x86_64_check_tls_transition (bfd *abfd,
  	  if (largepic)
  	    return r_type == R_X86_64_PLTOFF64;
  	  else if (indirect_call)
-	    return r_type == R_X86_64_GOTPCRELX;
+	    return (r_type == R_X86_64_GOTPCRELX || r_type == R_X86_64_GOTPCREL);
  	  else
  	    return (r_type == R_X86_64_PC32 || r_type == R_X86_64_PLT32);
  	}
-- 
2.40.0.rc0.216.gc4246ad0f0-goog

Re: [PATCH v2] ld: Allow R_X86_64_GOTPCREL for call *__tls_get_addr@GOTPCREL(%rip)

[Jan Beulich]

On 02.03.2023 21:10, Fangrui Song wrote:
>  From a8df373aec097dcdabe46717dd95cdd9b16ef7d7 Mon Sep 17 00:00:00 2001
> From: Fangrui Song <maskray@google.com>
> Date: Thu, 5 Jan 2023 12:45:27 -0800
> Subject: [PATCH v2] ld: Allow R_X86_64_GOTPCREL for call
>   *__tls_get_addr@GOTPCREL(%rip)
> 
> _Thread_local int a;
> int main() { return a; }
> 
> % gcc -fno-plt -fpic a.c -fuse-ld=bfd -Wa,-mrelax-relocations=no
> /usr/bin/ld.bfd: /tmp/ccSSBgrg.o: TLS transition from R_X86_64_TLSGD to R_X86_64_GOTTPOFF against `a' at 0xd in section `.text' failed
> /usr/bin/ld.bfd: failed to set dynamic section sizes: bad value
> collect2: error: ld returned 1 exit status
> 
> This commit fixes the issue.
> 
> There is an argument that the -fno-plt TLS sequence was added after
> R_X86_64_GOTPCRELX was required for call, so R_X86_64_GOTPCREL was
> intended to be unsupported.
> 
> Unfortunately this standpoint has caused interop difficulty: some
> projects specify -mrelax-relocations=no to build relocatable object
> files compatible with older linkers (e.g.
> https://github.com/IHaskell/IHaskell/issues/636) or do so by accident
> (e.g. https://github.com/rust-lang/rust/pull/106511 not addressed as of
> today).  Many uses have not been cleaned up in practice, and compiling
> with -fno-plt will lead to the `TLS transition from R_X86_64_TLSGD ...`
> error which is hard to reason about.
> 
> There is another argument which may be weaker but relevant to the
> necessity of -mrelax-relocations=no: HWAddressSanitizer x86-64 will
> likely need some assembler support to disable relaxation.  Without the
> support and if the compiler needs to support many gas versions, the
> simplest solutation would be to use -Wa,-mrelax-relocations=no.
> 
>      PR ld/24784
>      * bfd/elf64-x86-64.c (elf_x86_64_check_tls_transition): Allow
>        R_X86_64_GOTPCREL.
> ---
>   bfd/elf64-x86-64.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/bfd/elf64-x86-64.c b/bfd/elf64-x86-64.c
> index 0aa9af5d8fc..dd987ee011b 100644
> --- a/bfd/elf64-x86-64.c
> +++ b/bfd/elf64-x86-64.c
> @@ -1253,7 +1253,7 @@ elf_x86_64_check_tls_transition (bfd *abfd,
>   	  if (largepic)
>   	    return r_type == R_X86_64_PLTOFF64;
>   	  else if (indirect_call)
> -	    return r_type == R_X86_64_GOTPCRELX;
> +	    return (r_type == R_X86_64_GOTPCRELX || r_type == R_X86_64_GOTPCREL);
>   	  else
>   	    return (r_type == R_X86_64_PC32 || r_type == R_X86_64_PLT32);
>   	}

No further comments from H.J., so please feel free to commit.

Jan