[Bug ld/32443] New: ABS symbol value depends on its visibility

[srk31 at srcf dot ucam.org]

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

            Bug ID: 32443
           Summary: ABS symbol value depends on its visibility
           Product: binutils
           Version: 2.40
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: ld
          Assignee: unassigned at sourceware dot org
          Reporter: srk31 at srcf dot ucam.org
  Target Milestone: ---

Created attachment 15835
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15835&action=edit
reproducer

If I define an ABS symbol preemptibly in a shared object, such that its GOT
entry is relocated by the ld.so and a `R_*_GLOB_DAT` relocation, the ABS symbol
takes the value I expect.
```
$ grep . exe.c lib.c lib.lds
exe.c:extern void lib_func(void);
exe.c:int main(void)
exe.c:{
exe.c:  lib_func();
exe.c:}
lib.c:#include <stdio.h>
lib.c:extern void value;
lib.c:void lib_func(void)
lib.c:{
lib.c:  printf("In lib, value is %lx\n", (long) &value);
lib.c:}
lib.lds:PROVIDE (value = 42);
$ cc -fPIC -shared -o lib.so lib.c lib.lds -Wl,-rpath,`pwd`
$ cc -fPIC -o exe  exe.c lib.so -Wl,-rpath,`pwd`
$ ./exe
exe: In lib, value is 2a
```
But if I make the same symbol non-preemptible, without changing its value (and
noting that it is *not* preempted in this scenario), its value gets the
library's load address added to it.
```
$ grep . lib-hidden.lds
PROVIDE_HIDDEN (value = 42);
$ cc -fPIC -shared -o lib-hidden.so lib.c lib-hidden.lds -Wl,-rpath,`pwd`
$ cc -fPIC -o exe-hidden  exe.c lib-hidden.so -Wl,-rpath,`pwd`
$ ./exe-hidden
exe-hidden: In lib, value is 7fe650c5c02a
```
The problem is that the GOT entry is now relocated differently: by
`R_*_RELATIVE`, not `R_*_GLOB_DAT`. Once `R_*_RELATIVE` is applied, of course
the load address will inevitably be added.

I suspect that for ABS symbols, these `R_*_RELATIVE` relocations on the GOT
entries should not be generated. This would generate behaviour consistent with
the `R_*_GLOB_DAT` case, giving the ABS section's address as (always) "zero in
the global address space", not sometimes-yes-sometimes-not "zero in the shared
object's address space".

-- 
You are receiving this mail because:
You are on the CC list for the bug.