[llvm-dev] lld symbol choice for symbol present in both a shared and a static library, with and without LTO

Eli Friedman via llvm-dev llvm-dev at lists.llvm.org
Fri Jun 14 12:58:14 PDT 2019


I filed https://bugs.llvm.org/show_bug.cgi?id=42273 last night, about an inconsistency between LTO and non-LTO workflows.

The basic scenario is that we have an object file which calls a function "foo", a static library that provides an implementation of "foo", and a shared library that also provides an implementation of "foo".  Currently, whether lld chooses the symbol from the static library or the shared library depends on the order the files are specified on the command-line.  For "obj.o static.a shared.so", or "static.a obj.o shared.so", lld chooses the symbol from the static library. For any other order, it chooses the symbol from the shared library.  Is this the expected behavior?  (As far as I can tell, this matches binutils ld except for the "static.a obj.o shared.so" case.)

If "obj.o" is built with LTO enabled, and the function is specifically a runtime function, the behavior is different.  For example, suppose the IR contains a call to "llvm.memcpy", and the generated code eventually calls "memcpy".  Or suppose the IR contains a "resume" instruction, and the generated code eventually calls "_Unwind_Resume".  In this case, the choice is different: lld always chooses the "memcpy" or "_Unwind_Resume" from the shared library, ignoring the order the files are specified on the command-line.  Is this the expected behavior?

-Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190614/13f85090/attachment.html>


More information about the llvm-dev mailing list