<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jun 17, 2019 at 4:15 AM Rui Ueyama via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<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 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" target="_blank">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_-1338818012673125959gmail-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_-1338818012673125959gmail-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></blockquote><div><br></div><div>I believe this is going to be specific to builtin functions. The reason is that the LTO link is fed by bitcode files, which at this point have references to the llvm intrinsic, not the library call. So the linker, which invokes the LTO compilation and provides the symbol resolutions, does not see any call to e.g. "memcpy". Later, in the LTO backends, the intrinsic gets turned into something, depending on the compiler's heuristics. This something could be an inline expansion of memcpy, or a regular call to memcpy.</div><div><br></div><div>For these libcalls, to avoid this behavior build with -fno-builtin-memcpy (or other libcall name), or more generally, -fno-builtin or -ffreestanding to block them all.</div><div><br></div><div>Teresa</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">
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><span style="font-family:Times;font-size:medium"><table cellspacing="0" cellpadding="0"><tbody><tr style="color:rgb(85,85,85);font-family:sans-serif;font-size:small"><td nowrap style="border-top:2px solid rgb(213,15,37)">Teresa Johnson |</td><td nowrap style="border-top:2px solid rgb(51,105,232)"> Software Engineer |</td><td nowrap style="border-top:2px solid rgb(0,153,57)"> <a href="mailto:tejohnson@google.com" target="_blank">tejohnson@google.com</a> |</td><td nowrap style="border-top:2px solid rgb(238,178,17)"><br></td></tr></tbody></table></span></div></div></div></div>