<div dir="ltr"><div dir="ltr">On Sat, Jun 15, 2019 at 4:58 AM Eli Friedman via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">





<div lang="EN-US">
<div class="gmail-m_8261370493228121197WordSection1">
<p class="MsoNormal">I filed <a href="https://bugs.llvm.org/show_bug.cgi?id=42273" target="_blank">
https://bugs.llvm.org/show_bug.cgi?id=42273</a> last night, about an inconsistency between LTO and non-LTO workflows.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">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.)</p></div></div></blockquote><div><br></div><div>This is what I expected. When lld visits an object file A and find an undefined symbol, and there's a file B that appears before the object file in the command line that defines the symbol, then B gets linked. If there's more than one file that define the symbol, the leftmost one is chosen.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_8261370493228121197WordSection1">
<p class="MsoNormal">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?</p></div></div></blockquote><div><br></div><div>That's not expected, but I suspect that that only occurs when you use a builtin function like memcpy. Does this happen when you define some random function like "foo"?</div></div></div>