https://sourceware.org/bugzilla/show_bug.cgi?id=29655
Ulrich Weigand changed:
What|Removed |Added
CC||uweigand at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=29655
--- Comment #8 from Ulrich Weigand ---
(In reply to Rui Ueyama from comment #7)
> A main executable's PLT entry that is used as a function address is often
> called a "canonical PLT".
>
> If the main executable isn't compiled as PIC, and if i
https://sourceware.org/bugzilla/show_bug.cgi?id=29655
--- Comment #10 from Ulrich Weigand ---
(In reply to Rui Ueyama from comment #9)
> However, the PLT address is not used as its function address as you can see
> below.
>
> $ ./test1
> foo=0x7f60482d3110 bar=0x7f60482d3120
Well, when I r
https://sourceware.org/bugzilla/show_bug.cgi?id=29655
--- Comment #13 from Ulrich Weigand ---
In any case, I still don't quite get where there is any incompatibility.
If `bar` resolves to its canonical PLT address, and you use `--defsym=foo=bar`,
then `foo` will *also* resolve to the canonical P
https://sourceware.org/bugzilla/show_bug.cgi?id=29655
--- Comment #15 from Ulrich Weigand ---
Thanks for the test case! A few comments:
1. In this scenario, it is indeed not guaranteed that fn1 compares equal to
fn1_public everywhere. This is because fn1 is declared hidden in libfoo.c, so
all
