https://llvm.org/bugs/show_bug.cgi?id=31476
Rafael Ávila de Espíndola <rafael.espind...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |INVALID
--- Comment #1 from Rafael Ávila de Espíndola <rafael.espind...@gmail.com> ---
At least in this repro this is the intended behaviour.
The issue is as follows:
In bar.o the function is accessed directly, not via a got or plt. That decision
is done by the compiler before we get to the linker.
The linker finds out that the function is actually defined in a .so, and the
final value is not know until runtime, so it cannot in general finish the link.
There are two special last resorts that the linker has:
* Produce a copy relocation, asking the dynamic linker to copy the value to a
known location. This doesn't work for functions as their size is expected to
change in different versions of the .so.
* Produce a dummy symbol for foo in the main binary and point it to a plt entry
that resolves to the real function in the .so. This works because for default
visibility symbols the executable is the first location the dynamic linker
looks and so the plt entry becomes the runtime address of the function.
With protected visibility we cannot use the second trick either as the .so can
have a direct access to the protected symbol which the dynamic linker would
have no way to preempt.
What is needed is for the call to foo in the the executable to use a plt or a
got. Long term clang will hopefully support that with __attribute__
((dllimport)) or similar (see http://reviews.llvm.org/D20217)
For now you should be able to build the executable with -fPIE.
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
