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)

Reply via email to