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

[uweigand at gcc dot gnu.org]

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

--- Comment #8 from Ulrich Weigand <uweigand at gcc dot gnu.org> ---
(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 it takes a pointer of
> imported function `foo`, the linker has to make the main program's `foo`'s
> PLT entry canonical. If it's not canonical, the main executable would use
> its own PLT entry as `foo`'s address, while other shared object files in
> memory would use `foo`'s real address of its address, which breaks the
> pointer equality guarantee.
> 
> Now, we can ask this question: is it safe to always make main executable's
> PLT entries canonical? I originally thought that the answer would be yes.
> Even if the main program is compiled with -fPIC, it seems that we can still
> make `foo`'s PLT entry canonical, so that the PLT entry's address will be
> used as `foo`'s address throughout the program execution.

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.

This is the logic we've been using all along, and it seems to have been
working correctly everywhere ...

> The above logic wasn't wrong, but in reality, there are libraries that
> assume the linker doesn't make PLT entries canonical unless necessary. Qt5
> is one of such libraries. It's `connect` function takes a pointer to a
> callback function. Internally, it compares a given pointer value with a list
> of pointers. When doing so, it looks like Qt compares a given pointer with
> addresses of symbol aliases. It works as long as both pointers directly
> point to the address of a callback function. But it won't when a given
> pointer points to a PLT entry of the main executable. That caused a
> mysterious runtime issue. So I made a change to mold so that it makes PLT
> entries canonical only when needed (i.e. only when a function address is
> taken, as opposed to function is just called.)

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 are receiving this mail because:
You are on the CC list for the bug.