* [Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation
2020-03-29 21:05 [Bug other/94391] New: gcc refers to absolute symbols with R_X86_64_PC32 relocation yshuiv7 at gmail dot com
@ 2020-03-29 21:17 ` pinskia at gcc dot gnu.org
2020-03-29 23:34 ` yshuiv7 at gmail dot com
` (21 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: pinskia at gcc dot gnu.org @ 2020-03-29 21:17 UTC (permalink / raw)
To: gcc-bugs
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" \
)
^ permalink raw reply [flat|nested] 24+ messages in thread
* [Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation
2020-03-29 21:05 [Bug other/94391] New: gcc refers to absolute symbols with R_X86_64_PC32 relocation yshuiv7 at gmail dot com
2020-03-29 21:17 ` [Bug target/94391] " pinskia at gcc dot gnu.org
@ 2020-03-29 23:34 ` yshuiv7 at gmail dot com
2020-03-29 23:37 ` pinskia at gcc dot gnu.org
` (20 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: yshuiv7 at gmail dot com @ 2020-03-29 23:34 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 24+ messages in thread
* [Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation
2020-03-29 21:05 [Bug other/94391] New: gcc refers to absolute symbols with R_X86_64_PC32 relocation yshuiv7 at gmail dot com
2020-03-29 21:17 ` [Bug target/94391] " pinskia at gcc dot gnu.org
2020-03-29 23:34 ` yshuiv7 at gmail dot com
@ 2020-03-29 23:37 ` pinskia at gcc dot gnu.org
2020-03-29 23:51 ` hjl.tools at gmail dot com
` (19 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: pinskia at gcc dot gnu.org @ 2020-03-29 23:37 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 24+ messages in thread
* [Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation
2020-03-29 21:05 [Bug other/94391] New: gcc refers to absolute symbols with R_X86_64_PC32 relocation yshuiv7 at gmail dot com
` (2 preceding siblings ...)
2020-03-29 23:37 ` pinskia at gcc dot gnu.org
@ 2020-03-29 23:51 ` hjl.tools at gmail dot com
2020-03-30 2:40 ` i at maskray dot me
` (18 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: hjl.tools at gmail dot com @ 2020-03-29 23:51 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 24+ messages in thread
* [Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation
2020-03-29 21:05 [Bug other/94391] New: gcc refers to absolute symbols with R_X86_64_PC32 relocation yshuiv7 at gmail dot com
` (3 preceding siblings ...)
2020-03-29 23:51 ` hjl.tools at gmail dot com
@ 2020-03-30 2:40 ` i at maskray dot me
2020-03-30 2:42 ` i at maskray dot me
` (17 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: i at maskray dot me @ 2020-03-30 2:40 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 24+ messages in thread
* [Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation
2020-03-29 21:05 [Bug other/94391] New: gcc refers to absolute symbols with R_X86_64_PC32 relocation yshuiv7 at gmail dot com
` (4 preceding siblings ...)
2020-03-30 2:40 ` i at maskray dot me
@ 2020-03-30 2:42 ` i at maskray dot me
2020-03-30 2:45 ` pinskia at gcc dot gnu.org
` (16 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: i at maskray dot me @ 2020-03-30 2:42 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 24+ messages in thread
* [Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation
2020-03-29 21:05 [Bug other/94391] New: gcc refers to absolute symbols with R_X86_64_PC32 relocation yshuiv7 at gmail dot com
` (5 preceding siblings ...)
2020-03-30 2:42 ` i at maskray dot me
@ 2020-03-30 2:45 ` pinskia at gcc dot gnu.org
2020-03-30 2:46 ` pinskia at gcc dot gnu.org
` (15 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: pinskia at gcc dot gnu.org @ 2020-03-30 2:45 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 24+ messages in thread
* [Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation
2020-03-29 21:05 [Bug other/94391] New: gcc refers to absolute symbols with R_X86_64_PC32 relocation yshuiv7 at gmail dot com
` (6 preceding siblings ...)
2020-03-30 2:45 ` pinskia at gcc dot gnu.org
@ 2020-03-30 2:46 ` pinskia at gcc dot gnu.org
2020-03-30 3:48 ` hjl.tools at gmail dot com
` (14 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: pinskia at gcc dot gnu.org @ 2020-03-30 2:46 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 24+ messages in thread
* [Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation
2020-03-29 21:05 [Bug other/94391] New: gcc refers to absolute symbols with R_X86_64_PC32 relocation yshuiv7 at gmail dot com
` (7 preceding siblings ...)
2020-03-30 2:46 ` pinskia at gcc dot gnu.org
@ 2020-03-30 3:48 ` hjl.tools at gmail dot com
2020-03-30 4:14 ` i at maskray dot me
` (13 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: hjl.tools at gmail dot com @ 2020-03-30 3:48 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 24+ messages in thread
* [Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation
2020-03-29 21:05 [Bug other/94391] New: gcc refers to absolute symbols with R_X86_64_PC32 relocation yshuiv7 at gmail dot com
` (8 preceding siblings ...)
2020-03-30 3:48 ` hjl.tools at gmail dot com
@ 2020-03-30 4:14 ` i at maskray dot me
2020-03-30 9:29 ` yshuiv7 at gmail dot com
` (12 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: i at maskray dot me @ 2020-03-30 4:14 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* [Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation
2020-03-29 21:05 [Bug other/94391] New: gcc refers to absolute symbols with R_X86_64_PC32 relocation yshuiv7 at gmail dot com
` (9 preceding siblings ...)
2020-03-30 4:14 ` i at maskray dot me
@ 2020-03-30 9:29 ` yshuiv7 at gmail dot com
2020-03-30 11:01 ` hjl.tools at gmail dot com
` (11 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: yshuiv7 at gmail dot com @ 2020-03-30 9:29 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 24+ messages in thread
* [Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation
2020-03-29 21:05 [Bug other/94391] New: gcc refers to absolute symbols with R_X86_64_PC32 relocation yshuiv7 at gmail dot com
` (10 preceding siblings ...)
2020-03-30 9:29 ` yshuiv7 at gmail dot com
@ 2020-03-30 11:01 ` hjl.tools at gmail dot com
2020-03-30 12:22 ` hjl.tools at gmail dot com
` (10 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: hjl.tools at gmail dot com @ 2020-03-30 11:01 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 24+ messages in thread
* [Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation
2020-03-29 21:05 [Bug other/94391] New: gcc refers to absolute symbols with R_X86_64_PC32 relocation yshuiv7 at gmail dot com
` (11 preceding siblings ...)
2020-03-30 11:01 ` hjl.tools at gmail dot com
@ 2020-03-30 12:22 ` hjl.tools at gmail dot com
2020-03-30 12:42 ` hjl.tools at gmail dot com
` (9 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: hjl.tools at gmail dot com @ 2020-03-30 12:22 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 24+ messages in thread
* [Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation
2020-03-29 21:05 [Bug other/94391] New: gcc refers to absolute symbols with R_X86_64_PC32 relocation yshuiv7 at gmail dot com
` (12 preceding siblings ...)
2020-03-30 12:22 ` hjl.tools at gmail dot com
@ 2020-03-30 12:42 ` hjl.tools at gmail dot com
2020-03-30 16:14 ` yshuiv7 at gmail dot com
` (8 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: hjl.tools at gmail dot com @ 2020-03-30 12:42 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* [Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation
2020-03-29 21:05 [Bug other/94391] New: gcc refers to absolute symbols with R_X86_64_PC32 relocation yshuiv7 at gmail dot com
` (13 preceding siblings ...)
2020-03-30 12:42 ` hjl.tools at gmail dot com
@ 2020-03-30 16:14 ` yshuiv7 at gmail dot com
2020-03-30 20:15 ` hjl.tools at gmail dot com
` (7 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: yshuiv7 at gmail dot com @ 2020-03-30 16:14 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 24+ messages in thread
* [Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation
2020-03-29 21:05 [Bug other/94391] New: gcc refers to absolute symbols with R_X86_64_PC32 relocation yshuiv7 at gmail dot com
` (14 preceding siblings ...)
2020-03-30 16:14 ` yshuiv7 at gmail dot com
@ 2020-03-30 20:15 ` hjl.tools at gmail dot com
2020-03-30 23:27 ` yshuiv7 at gmail dot com
` (6 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: hjl.tools at gmail dot com @ 2020-03-30 20:15 UTC (permalink / raw)
To: gcc-bugs
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);
}
^ permalink raw reply [flat|nested] 24+ messages in thread
* [Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation
2020-03-29 21:05 [Bug other/94391] New: gcc refers to absolute symbols with R_X86_64_PC32 relocation yshuiv7 at gmail dot com
` (15 preceding siblings ...)
2020-03-30 20:15 ` hjl.tools at gmail dot com
@ 2020-03-30 23:27 ` yshuiv7 at gmail dot com
2020-03-30 23:31 ` pinskia at gcc dot gnu.org
` (5 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: yshuiv7 at gmail dot com @ 2020-03-30 23:27 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 24+ messages in thread
* [Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation
2020-03-29 21:05 [Bug other/94391] New: gcc refers to absolute symbols with R_X86_64_PC32 relocation yshuiv7 at gmail dot com
` (16 preceding siblings ...)
2020-03-30 23:27 ` yshuiv7 at gmail dot com
@ 2020-03-30 23:31 ` pinskia at gcc dot gnu.org
2020-03-30 23:33 ` yshuiv7 at gmail dot com
` (4 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: pinskia at gcc dot gnu.org @ 2020-03-30 23:31 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 24+ messages in thread
* [Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation
2020-03-29 21:05 [Bug other/94391] New: gcc refers to absolute symbols with R_X86_64_PC32 relocation yshuiv7 at gmail dot com
` (17 preceding siblings ...)
2020-03-30 23:31 ` pinskia at gcc dot gnu.org
@ 2020-03-30 23:33 ` yshuiv7 at gmail dot com
2020-03-30 23:34 ` yshuiv7 at gmail dot com
` (3 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: yshuiv7 at gmail dot com @ 2020-03-30 23:33 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 24+ messages in thread
* [Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation
2020-03-29 21:05 [Bug other/94391] New: gcc refers to absolute symbols with R_X86_64_PC32 relocation yshuiv7 at gmail dot com
` (18 preceding siblings ...)
2020-03-30 23:33 ` yshuiv7 at gmail dot com
@ 2020-03-30 23:34 ` yshuiv7 at gmail dot com
2020-03-30 23:36 ` pinskia at gcc dot gnu.org
` (2 subsequent siblings)
22 siblings, 0 replies; 24+ messages in thread
From: yshuiv7 at gmail dot com @ 2020-03-30 23:34 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 24+ messages in thread
* [Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation
2020-03-29 21:05 [Bug other/94391] New: gcc refers to absolute symbols with R_X86_64_PC32 relocation yshuiv7 at gmail dot com
` (19 preceding siblings ...)
2020-03-30 23:34 ` yshuiv7 at gmail dot com
@ 2020-03-30 23:36 ` pinskia at gcc dot gnu.org
2020-03-30 23:39 ` yshuiv7 at gmail dot com
2020-03-31 1:26 ` i at maskray dot me
22 siblings, 0 replies; 24+ messages in thread
From: pinskia at gcc dot gnu.org @ 2020-03-30 23:36 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 24+ messages in thread
* [Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation
2020-03-29 21:05 [Bug other/94391] New: gcc refers to absolute symbols with R_X86_64_PC32 relocation yshuiv7 at gmail dot com
` (20 preceding siblings ...)
2020-03-30 23:36 ` pinskia at gcc dot gnu.org
@ 2020-03-30 23:39 ` yshuiv7 at gmail dot com
2020-03-31 1:26 ` i at maskray dot me
22 siblings, 0 replies; 24+ messages in thread
From: yshuiv7 at gmail dot com @ 2020-03-30 23:39 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 24+ messages in thread
* [Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation
2020-03-29 21:05 [Bug other/94391] New: gcc refers to absolute symbols with R_X86_64_PC32 relocation yshuiv7 at gmail dot com
` (21 preceding siblings ...)
2020-03-30 23:39 ` yshuiv7 at gmail dot com
@ 2020-03-31 1:26 ` i at maskray dot me
22 siblings, 0 replies; 24+ messages in thread
From: i at maskray dot me @ 2020-03-31 1:26 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 24+ messages in thread