[Bug other/94391] New: gcc refers to absolute symbols with R_X86_64_PC32 relocation

[Bug other/94391] New: gcc refers to absolute symbols with R_X86_64_PC32 relocation

[yshuiv7 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391

            Bug ID: 94391
           Summary: gcc refers to absolute symbols with R_X86_64_PC32
                    relocation
           Product: gcc
           Version: 9.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: other
          Assignee: unassigned at gcc dot gnu.org
          Reporter: yshuiv7 at gmail dot com
  Target Milestone: ---

Test case:

Source file (a.c):
    extern char _binary_a_c_size[];
    unsigned long foo() { return (unsigned long)_binary_a_c_size; }

Run:
    objcopy -B i386:x86-64 -I binary -O elf64-x86-64 a.c b.o
    gcc -fuse-ld=lld -fpie -pie a.c b.o

lld complains about:

ld.lld: error: relocation R_X86_64_PC32 cannot refer to absolute symbol:
_binary_a_c_size
>>> defined in b.o
>>> referenced by a.c
>>>               /tmp/cc3iReeC.o:(foo)


Also, this seems to be more than just a problem in gcc. Doing the same test
with clang+lld yields the expected results. However, with clang+gold/bfd, the
absolute symbol is relocated.

[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I think this is a bug in LLVM's lld.

http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20170116/420892.html

     2: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT    1 _binary_t85_c_start
     3: 00000000000002c8     0 NOTYPE  GLOBAL DEFAULT    1 _binary_t85_c_end
     4: 00000000000002c8     0 NOTYPE  GLOBAL DEFAULT  ABS _binary_t85_c_size

You cannot refer to this symbol directly from C code.
What I do in my code is the following top level inline-asm:
#define SIZE_SECTION(section)   \
asm(                            \
".pushsection .rodata\n"        \
".align 8\n"                    \
".global __size_" section "\n"  \
"__size_" section ":\n"         \
".xword .sizeof.." section "\n" \
".popsection\n"                 \
)

[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation

[yshuiv7 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391

Yuxuan Shui <yshuiv7 at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |---

--- Comment #2 from Yuxuan Shui <yshuiv7 at gmail dot com> ---
If you read the reply, you will find out that is not the same bug as this:


> This is an over reduction. The real problem is that we are not tracking
> absoluteness correctly. In the original case vvar_vsyscall_gtod_data
> should not be absolute

> > --- ELF/Relocations.cpp
> > +++ ELF/Relocations.cpp
> > @@ -356,6 +356,10 @@
> >        return true;
> >      if (&Body == ElfSym<ELFT>::MipsGpDisp)
> >        return true;
> > +    // Sometimes code has relocations to absolute symbol defined in linker script.
> > +    // Example is linux kernel. Hence we allow it.
> > +    if (!Body.File)
> > +      return true;

> We should not do this. It would accept broken cases too.

[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |WONTFIX
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
As I mentioned these symbols are special. You cant use them as normal symbols. 
Instead you need to like I did.

[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|WONTFIX                     |WORKSFORME

--- Comment #4 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Yuxuan Shui from comment #0)
> Test case:
> 
> Source file (a.c):
>     extern char _binary_a_c_size[];
>     unsigned long foo() { return (unsigned long)_binary_a_c_size; }

Try

---
extern unsigned long _binary_a_c_size;
unsigned long foo() { return _binary_a_c_size; }
---

> Run:
>     objcopy -B i386:x86-64 -I binary -O elf64-x86-64 a.c b.o
>     gcc -fuse-ld=lld -fpie -pie a.c b.o
> 
> lld complains about:
> 
> ld.lld: error: relocation R_X86_64_PC32 cannot refer to absolute symbol:
> _binary_a_c_size

This is an lld bug.

[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation

[i at maskray dot me]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391

Fangrui Song <i at maskray dot me> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |i at maskray dot me

--- Comment #5 from Fangrui Song <i at maskray dot me> ---
This bug exposes several problems:

* GNU ld does not reject a PC-relative relocation referencing a SHN_ABS symbol
* GCC should not produce R_X86_64_PC32 referencing an external symbol in -fpie
mode. 

% gcc -fuse-ld=lld -nostdlib -fpie -pie a.c
% objdump -dr a.o
...
0000000000000000 <foo>:
   0:   55                      push   %rbp
   1:   48 89 e5                mov    %rsp,%rbp
   4:   48 8d 05 00 00 00 00    lea    0x0(%rip),%rax        # b <foo+0xb>
                        7: R_X86_64_PC32        _binary_a_c_size-0x4
   b:   5d                      pop    %rbp
   c:   c3                      retq

% gcc -fuse-ld=bfd -nostdlib -fpie -pie a.c b.o -o a
/usr/bin/ld.bfd: warning: cannot find entry symbol _start; defaulting to
0000000000001000
% objdump -dr a
...
0000000000001000 <foo>:
    1000:       55                      push   %rbp
    1001:       48 89 e5                mov    %rsp,%rbp
    1004:       48 8d 05 39 f0 ff ff    lea    -0xfc7(%rip),%rax        # 44
<_binary_a_c_size>
    100b:       5d                      pop    %rbp
    100c:       c3                      retq

It is incorrect to reference a non-preemptible symbol with a PC relative
relocation in a -pie link. GNU ld allows it but the code can be incorrect at
runtime.

lea    -0xfc7(%rip),%rax  # loads 44 to %rax only if the load base is 0. Due to
ASLR (-pie), this is simply not true.

lld correctly rejects the relocation.

To fix this, I had a write-up last year:
https://gcc.gnu.org/legacy-ml/gcc/2019-05/msg00215.html
We should change the configure-time HAVE_LD_PIE_COPYRELOC to an option,
probably -f(no-)direct-access-extern

In clang, HAVE_LD_PIE_COPYRELOC is a compile-time option:
-mpie-copy-relocations. But I think we should improve the option name. At the
very least, we can also let -fno-pic code reference an external symbol with GOT
to avoid copy relocations. -f(no-)direct-access-extern may be a candidate.

[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation

[i at maskray dot me]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391

--- Comment #6 from Fangrui Song <i at maskray dot me> ---
> It is incorrect to reference a non-preemptible symbol with a PC relative relocation in a -pie link. GNU ld allows it but the code can be incorrect at runtime.

Correction: It is incorrect to reference a non-preemptible SHN_ABS symbol with
a PC relative relocation in a PIC (-shared or -pie) link. This is
non-representable due to ASLR (load base not fixed at link time)

[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Fangrui Song from comment #5)
> This bug exposes several problems:
> 
> * GNU ld does not reject a PC-relative relocation referencing a SHN_ABS
> symbol
> * GCC should not produce R_X86_64_PC32 referencing an external symbol in
> -fpie mode. 

NO LLD is not implemented the ABI as PIE COPYRELOC is required by the ABI these
days.

[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391

--- Comment #8 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Also it is wrong for a person to assume a normal C variable could be SHN_ABS;
that is the bug here.  It is a bug in the user code.
I showed up to fix it by using an top level inline-asm.

[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391

--- Comment #9 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Fangrui Song from comment #5)
> This bug exposes several problems:
> 
> * GNU ld does not reject a PC-relative relocation referencing a SHN_ABS
> symbol
> * GCC should not produce R_X86_64_PC32 referencing an external symbol in
> -fpie mode. 
> 
> % gcc -fuse-ld=lld -nostdlib -fpie -pie a.c
> % objdump -dr a.o
> ...
> 0000000000000000 <foo>:
>    0:   55                      push   %rbp
>    1:   48 89 e5                mov    %rsp,%rbp
>    4:   48 8d 05 00 00 00 00    lea    0x0(%rip),%rax        # b <foo+0xb>
>                         7: R_X86_64_PC32        _binary_a_c_size-0x4
>    b:   5d                      pop    %rbp
>    c:   c3                      retq
> 
> % gcc -fuse-ld=bfd -nostdlib -fpie -pie a.c b.o -o a
> /usr/bin/ld.bfd: warning: cannot find entry symbol _start; defaulting to
> 0000000000001000
> % objdump -dr a
> ...
> 0000000000001000 <foo>:
>     1000:       55                      push   %rbp
>     1001:       48 89 e5                mov    %rsp,%rbp
>     1004:       48 8d 05 39 f0 ff ff    lea    -0xfc7(%rip),%rax        # 44
> <_binary_a_c_size>
>     100b:       5d                      pop    %rbp
>     100c:       c3                      retq
> 
> It is incorrect to reference a non-preemptible symbol with a PC relative
> relocation in a -pie link. GNU ld allows it but the code can be incorrect at
> runtime.
> 
> lea    -0xfc7(%rip),%rax  # loads 44 to %rax only if the load base is 0. Due
> to ASLR (-pie), this is simply not true.

Your are using the incorrect user code.  Please use

---
extern unsigned long _binary_a_c_size;
unsigned long foo() { return _binary_a_c_size; }
---

GCC and ld handle it correctly.

[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation

[i at maskray dot me]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391

--- Comment #10 from Fangrui Song <i at maskray dot me> ---
> extern unsigned long _binary_a_c_size;
> unsigned long foo() { return _binary_a_c_size; }

This is incorrect. The code will treat the value of _binary_a_c_size as an
address (load base + size) and dereference that address
mov    -0xfc3(%rip),%rax        # 44 <_binary_a_c_size>

> NO LLD is not implemented the ABI as PIE COPYRELOC is required by the ABI these days.

My objdump -d output in Comment #5 demonstrates that GNU ld linked code will be
incorrect at runtime.
It can be argued that either the user code or GCC does the wrong thing, but a
linker is not responsible for the mistake.
(I have argued lld does the right thing by erroring at link time.)

The compiler can ask the assembler to produce an indirect (GOT) reference.
The code (`unsigned long foo() { return (unsigned long)_binary_a_c_size; })
will work perfectly.

> Also it is wrong for a person to assume a normal C variable could be SHN_ABS; that is the bug here.
> It is a bug in the user code.
> I showed up to fix it by using an top level inline-asm.

-fno-pic and -fpic work fine. -fpie before commit
77ad54d911dd7cb88caf697ac213929f6132fdcf worked fine.



commit 77ad54d911dd7cb88caf697ac213929f6132fdcf ("x86-64: Optimize access to
globals in PIE with copy reloc")
is responsible for the -fpie change.
In 2015, H.J. invented R_X86_64_{REX,}GOTPCRELX. The linker relaxation is a
perfect solution.
We can retire HAVE_LD_PIE_COPYREL now.


// The code will still be faulty but we can argue that it is an user error.
__attribute__((visibility("hidden"))) extern unsigned long _binary_a_c_size;
unsigned long foo() { return _binary_a_c_size; }


The relaxed R_X86_64_{REX,}GOTPCRELX will be a bit longer than R_X86_64_PC32.
The difference is small enough and should not matter for practical use cases.
For those who care about the tiny regression, we can invent an option
-fdirect-access-extern (clang currently calls it -mpie-copy-relocations but we
can design a better name).
It is more useful on non-x86 architectures for a mostly statically linked
program.

extern int var; int foo(void) { return var; }

// clang -target aarch64 -fPIE -O3
        adrp    x8, :got:var
        ldr     x8, [x8, :got_lo12:var]
        ldr     w0, [x8]
        ret
// clang -target aarch64 -fPIE -O3 -mpie-copy-relocations
        adrp    x8, var
        ldr     w0, [x8, :lo12:var]
        ret

// x86-64
// clang -O3 -fPIE a.c -Wa,--mrelax-relocations=yes
    0:   48 8b 05 00 00 00 00    mov    0x0(%rip),%rax        # 7 <foo+0x7>
                         3: R_X86_64_REX_GOTPCRELX       var-0x4
    7:   8b 00                   mov    (%rax),%eax
    9:   c3                      retq
// clang -O3 -fPIE a.c -mpie-copy-relocations
    0:   8b 05 00 00 00 00       mov    0x0(%rip),%eax        # 6 <foo+0x6>
                         2: R_X86_64_PC32        var-0x4
    6:   c3                      retq

[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation

[yshuiv7 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391

--- Comment #11 from Yuxuan Shui <yshuiv7 at gmail dot com> ---
(In reply to Andrew Pinski from comment #8)
> Also it is wrong for a person to assume a normal C variable could be
> SHN_ABS; that is the bug here.  It is a bug in the user code.
> I showed up to fix it by using an top level inline-asm.

Why is this wrong? Is it written down somewhere that a C variable can never be
SHN_ABS, perhaps in the standard, or in the X86-psABI?

If this is wrong, then what is the correct way to access a SHN_ABS symbol? Is
it just no way to do it? If so, what's the purpose of objcopy generating such
symbols?

[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391

--- Comment #12 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Yuxuan Shui from comment #11)
> (In reply to Andrew Pinski from comment #8)
> > Also it is wrong for a person to assume a normal C variable could be
> > SHN_ABS; that is the bug here.  It is a bug in the user code.
> > I showed up to fix it by using an top level inline-asm.
> 
> Why is this wrong? Is it written down somewhere that a C variable can never
> be SHN_ABS, perhaps in the standard, or in the X86-psABI?
> 
> If this is wrong, then what is the correct way to access a SHN_ABS symbol?
> Is it just no way to do it? If so, what's the purpose of objcopy generating
> such symbols?

Have you tried my way with ld?  Lld bug is a different issue.

[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391

--- Comment #13 from H.J. Lu <hjl.tools at gmail dot com> ---
The current relocation doesn't support PC32 relocation against SHN_ABS
in PIE nor shared library.  I will change ld to issue an error.

[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391

--- Comment #14 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to H.J. Lu from comment #13)
> The current relocation doesn't support PC32 relocation against SHN_ABS
> in PIE nor shared library.  I will change ld to issue an error.

I opened:

https://sourceware.org/bugzilla/show_bug.cgi?id=25749

[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation

[yshuiv7 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391

--- Comment #15 from Yuxuan Shui <yshuiv7 at gmail dot com> ---
(In reply to H.J. Lu from comment #12)
> (In reply to Yuxuan Shui from comment #11)
> > (In reply to Andrew Pinski from comment #8)
> > > Also it is wrong for a person to assume a normal C variable could be
> > > SHN_ABS; that is the bug here.  It is a bug in the user code.
> > > I showed up to fix it by using an top level inline-asm.
> > 
> > Why is this wrong? Is it written down somewhere that a C variable can never
> > be SHN_ABS, perhaps in the standard, or in the X86-psABI?
> > 
> > If this is wrong, then what is the correct way to access a SHN_ABS symbol?
> > Is it just no way to do it? If so, what's the purpose of objcopy generating
> > such symbols?
> 
> Have you tried my way with ld?  Lld bug is a different issue.

Your code is going to dereference the value stored in the ABS symbol as an
address (e.g. if the symbol has value 10, your code will access (*(char *)10),
barring the unwanted relocation), which is not the intention here.

[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391

--- Comment #16 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Yuxuan Shui from comment #15)
> Your code is going to dereference the value stored in the ABS symbol as an
> address (e.g. if the symbol has value 10, your code will access (*(char
> *)10), barring the unwanted relocation), which is not the intention here.

This works in all cases:

unsigned long
size2 (void)
{
  return ((unsigned long) &_binary_a_c_end
          - (unsigned long) &_binary_a_c_start);
}

[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation

[yshuiv7 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391

--- Comment #17 from Yuxuan Shui <yshuiv7 at gmail dot com> ---
(In reply to H.J. Lu from comment #16)
> (In reply to Yuxuan Shui from comment #15)
> > Your code is going to dereference the value stored in the ABS symbol as an
> > address (e.g. if the symbol has value 10, your code will access (*(char
> > *)10), barring the unwanted relocation), which is not the intention here.
> 
> This works in all cases:
> 
> unsigned long
> size2 (void)
> {
>   return ((unsigned long) &_binary_a_c_end
> 	  - (unsigned long) &_binary_a_c_start);
> }

Sorry, I am here to report a bug, not to find a workaround for my use case.

[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391

--- Comment #18 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Yuxuan Shui from comment #17)
> Sorry, I am here to report a bug, not to find a workaround for my use case.

I gave you the correct usage for your use case.  If you don't like it is not my
fault.

[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation

[yshuiv7 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391

Yuxuan Shui <yshuiv7 at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|WORKSFORME                  |---
             Status|RESOLVED                    |UNCONFIRMED

--- Comment #19 from Yuxuan Shui <yshuiv7 at gmail dot com> ---
comment #8 claims C variables cannot refer to ABS symbols without substantiate
that claim.

comment #9 suggests a change that is just wrong.

Reopening as previous WONTFIX/WORKSFORME resolutions are not valid.

[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation

[yshuiv7 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391

--- Comment #20 from Yuxuan Shui <yshuiv7 at gmail dot com> ---
(In reply to Andrew Pinski from comment #18)
> (In reply to Yuxuan Shui from comment #17)
> > Sorry, I am here to report a bug, not to find a workaround for my use case.
> 
> I gave you the correct usage for your use case.  If you don't like it is not
> my fault.

Can you please point me to something that shows me I am wrong?

Your suggestion is just a workaround as well, as it avoided using the ABS
symbol.

[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #21 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
>Your suggestion is just a workaround as well, as it avoided using the ABS symbol.

ABS symbols are invalid in PIE mode.  That is my point.

[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation

[yshuiv7 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391

Yuxuan Shui <yshuiv7 at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|INVALID                     |FIXED

--- Comment #22 from Yuxuan Shui <yshuiv7 at gmail dot com> ---
(In reply to Andrew Pinski from comment #21)
> >Your suggestion is just a workaround as well, as it avoided using the ABS symbol.
> 
> ABS symbols are invalid in PIE mode.  That is my point.

Well if that's the case, can you point me to something (Specs, standards, etc.)
that says ABS symbols are not allowed in PIE? Otherwise it's just your words.

[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation

[i at maskray dot me]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391

--- Comment #23 from Fangrui Song <i at maskray dot me> ---
(In reply to Andrew Pinski from comment #18)
> (In reply to Yuxuan Shui from comment #17)
> > Sorry, I am here to report a bug, not to find a workaround for my use case.
> 
> I gave you the correct usage for your use case.  If you don't like it is not
> my fault.

A wontfix/invalid does not seem a proper resolution to the bug(s).
We need a solution, instead of a workaround (SHN_ABS _binary_*_size can be
changed to _binary_*_end minus _binary_*_start).

Let me repeat. The code has worked fine for a long time.

1. -fno-pie code can only be linked with -no-pie. A PC32 relocation can be
resolved to a SHN_ABS definition.
2. -fpie code can be linked with either -no-pie or -pie.
3. -fpic code can be linked with -no-pie, -pie or -shared. GCC produces a GOT
relocation.
  The linker will fill up the GOT entry at link time. It is a constant at
runtime.

1 and 3 always work. For 2 -fpie -pie, it is incorrect to reference a
non-preemptible SHN_ABS symbol with a PC relative relocation in a PIC (-shared
or -pie) link (missed GNU ld diagnostic:
https://sourceware.org/bugzilla/show_bug.cgi?id=25749)

A GOT relocation was produced until commit
77ad54d911dd7cb88caf697ac213929f6132fdcf
("x86-64: Optimize access to globals in PIE with copy reloc").

I have proposed my solution in Comment 10: revert the patch.
It has very little value after H.J. invented GOTPCRELX in 2015.
As a compensation, we can invent a pair of new -f options,
-f(no-)direct-access-extern-object.

-fno-pie defaults to -fdirect-access-extern-object. -fpie defaults to
-fno-direct-access-extern-object.

-fno-pie users who really want to get rid of copy relocations can enable
-fno-direct-access-extern-object.
  Note: a copy relocation is needed if the definition turns out to be provided
by a shared object.

-fpie users who really care about GOT slowdown can enable
-fdirect-access-extern-object.
  This is more relevant on non-x86 due to the lack of linker relaxation
(R_X86_64_{REX_,}GOTPCRELX)