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.
