[Bug gas/29655] s390x gas generates PC32DBL instead of PLT32DBL for function call

[rui314 at gmail dot com]

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

--- Comment #9 from Rui Ueyama <rui314 at gmail dot com> ---
> My understanding is that the canonical function address of `foo` is the
> address of the PLT for `foo` in the main executable, *if such a PLT
> exists*, and the address of `foo` otherwise.  That PLT exists if the
> main executable references `foo`, but `foo` is not defined in the
> main executable.

No it's not the case with any of GNU ld, gold, lld or mold. You can see it in
action:

  $ cat test1.c
  void bar();
  int main() { bar(); }

  $ cat test2.c
  #include <stdio.h>
  void foo() {}
  void bar() { printf("foo=%p bar=%p\n", foo, bar); }

  $ cc -shared -fPIC -o test2.so test2.c
  $ cc -fuse-ld=bfd -no-pie -fno-PIC -o test1 test1.c ./test2.so

`test` has a PLT entry for `bar`, as it calls `bar` in a shared library. It's
address is 0x401020 in this particular test case

  $ readelf -S test | grep -F ' .plt'
  [13] .plt              PROGBITS        0000000000401020 001020 000020 10  AX 
0   0 16

However, the PLT address is not used as its function address as you can see
below.

  $ ./test1
  foo=0x7f60482d3110 bar=0x7f60482d3120

Both `foo` and `bar` are resolved to the .so's addresses.

But if you take an address of `foo` as below:

  $ cat test3.c
  void bar();
  void *get_bar_addr() { return bar; }
  int main() { bar(); }

then `bar` suddenly started to be resolved to the PLT entry as below:

  $ cc -fuse-ld=bfd -no-pie -fno-PIC -o test3 test3.c ./test2.so && ./test3
  foo=0x7fa538226110 bar=0x401030

> I don't quite understand the case.  These comparisons would all be
> between function pointers, so both sides of the comparison would be
> the result of "address taking" operations as you call it.  Whatever
> is done for "just-calling" operations does not matter either way
> for the result of such comparisons ...

You can create aliases to symbols using linker script or linker's
`--defsym=foo=bar` option. If you define foo as an alias to bar, you may assume
that they refer the same address, but if one symbol gets a canonical PLT and
the other don't, they'll refer different addresses. This is arguably a bug in
an application, but there are libraries such as Qt5 that assumes all programs
are compiled as PIC and therefore there's no canonical PLTs at all.

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