<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">My understanding is that the gold plugin already solves this problem by maintaining a list of such symbols (memcpy, memset, etc).</div><div class="gmail_quote"><br></div><div class="gmail_quote">_fltused is interesting, since we may end up linking the FP library when we otherwise wouldn't. We might be able to win it back with dead code stripping.</div><div class="gmail_quote"><br></div><div class="gmail_quote">On Mon, Jun 8, 2015 at 7:25 PM, Peter Collingbourne <span dir="ltr"><<a href="mailto:peter@pcc.me.uk" target="_blank">peter@pcc.me.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In general, the optimizer or code generator could create a reference to any<br>
C runtime library symbol, but the set of symbols is limited to those that it<br>
knows about. I don't believe we maintain a list of such symbols anywhere,<br>
and I'm a little concerned about the maintenance burden of such a list,<br>
as it could easily get out of sync with what LLVM uses.<br>
<br>
It could in principle also contain references to sanitizer runtime functions,<br>
but I believe that no existing sanitizer will create symbol references at<br>
LTO time.<br>
<br>
That said, if I revert this patch, I find that I need to create artificial<br>
references to __chkstk, _fltused, memcpy, memset and memmove in order<br>
to successfully link llvm-tblgen.exe. These symbols mostly seem fine, but<br>
_fltused is probably the most concerning, as I gather that it is part of an<br>
mechanism that causes the C runtime's floating point support to be optionally<br>
linked in if the program uses floating point arithmetic.<br>
<br>
With all that in mind, I'd slightly prefer to follow the approach given in<br>
my patch.<br>
<br>
Peter<br>
<div class="HOEnZb"><div class="h5"><br>
On Mon, Jun 08, 2015 at 06:27:46PM -0700, Rui Ueyama wrote:<br>
> __chkstk is a special symbol. Does the code generator introduce arbitrary<br>
> symbols? If not (if it could introduce only a limited set of symbols), we<br>
> may want to resolve them unconditionally as if they were specified with<br>
> /include.<br>
> 2015/06/08 午後6:00 "Peter Collingbourne" <<a href="mailto:peter@pcc.me.uk">peter@pcc.me.uk</a>>:<br>
><br>
> > Hi ruiu,<br>
> ><br>
> > The code generator may create references to runtime library symbols such as<br>
> > __chkstk which were not visible via LTOModule. Handle these cases by<br>
> > loading<br>
> > the object file from the library, but abort if we end up having loaded any<br>
> > bitcode objects.<br>
> ><br>
> > Because loading the object file may have introduced new undefined<br>
> > references,<br>
> > call reportRemainingUndefines again to detect and report them.<br>
> ><br>
> > <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D10332&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=mQ4LZ2PUj9hpadE3cDHZnIdEwhEBrbAstXeMaFoB9tg&m=DT-WWK7K6eSG96IvwWPf58IjaRgLimTTo-A7U1Ub-Gs&s=K6x7yFOP5qoQbwpZhgGMzOk-d-K_V5-ZYtz_K_1tHEI&e=" target="_blank">http://reviews.llvm.org/D10332</a><br>
> ><br>
> > Files:<br>
> > COFF/SymbolTable.cpp<br>
> > test/COFF/Inputs/lto-chkstk-chkstk.s<br>
> > test/COFF/Inputs/lto-chkstk-foo.s<br>
> > test/COFF/lto-chkstk.ll<br>
> ><br>
> > Index: COFF/SymbolTable.cpp<br>
> > ===================================================================<br>
> > --- COFF/SymbolTable.cpp<br>
> > +++ COFF/SymbolTable.cpp<br>
> > @@ -307,8 +307,27 @@<br>
> > return make_error_code(LLDError::BrokenFile);<br>
> > }<br>
> > }<br>
> > +<br>
> > + // We may see new references to runtime library symbols such as<br>
> > __chkstk<br>
> > + // here. These symbols must be wholly defined in non-bitcode files.<br>
> > + if (auto *B = dyn_cast<Lazy>(Sym->Body)) {<br>
> > + unsigned NumBitcodeFiles = BitcodeFiles.size();<br>
> > + auto EC = addMemberFile(B);<br>
> > + if (EC)<br>
> > + return EC;<br>
> > + if (BitcodeFiles.size() != NumBitcodeFiles) {<br>
> > + llvm::errs()<br>
> > + << "LTO: late loaded symbol created new bitcode reference: "<br>
> > << Name<br>
> > + << "\n";<br>
> > + return make_error_code(LLDError::BrokenFile);<br>
> > + }<br>
> > + }<br>
> > }<br>
> ><br>
> > + // New runtime library symbol references may have created undefined<br>
> > references.<br>
> > + if (reportRemainingUndefines())<br>
> > + return make_error_code(LLDError::BrokenFile);<br>
> > +<br>
> > return std::error_code();<br>
> > }<br>
> ><br>
> > Index: test/COFF/Inputs/lto-chkstk-chkstk.s<br>
> > ===================================================================<br>
> > --- /dev/null<br>
> > +++ test/COFF/Inputs/lto-chkstk-chkstk.s<br>
> > @@ -0,0 +1,3 @@<br>
> > +.globl __chkstk<br>
> > +__chkstk:<br>
> > +ret<br>
> > Index: test/COFF/Inputs/lto-chkstk-foo.s<br>
> > ===================================================================<br>
> > --- /dev/null<br>
> > +++ test/COFF/Inputs/lto-chkstk-foo.s<br>
> > @@ -0,0 +1,3 @@<br>
> > +.globl foo<br>
> > +foo:<br>
> > +ret<br>
> > Index: test/COFF/lto-chkstk.ll<br>
> > ===================================================================<br>
> > --- /dev/null<br>
> > +++ test/COFF/lto-chkstk.ll<br>
> > @@ -0,0 +1,17 @@<br>
> > +; RUN: llvm-as -o %t.obj %s<br>
> > +; RUN: llvm-mc -triple=x86_64-pc-windows-msvc -filetype=obj -o<br>
> > %T/lto-chkstk-foo.obj %S/Inputs/lto-chkstk-foo.s<br>
> > +; RUN: llvm-mc -triple=x86_64-pc-windows-msvc -filetype=obj -o<br>
> > %T/lto-chkstk-chkstk.obj %S/Inputs/lto-chkstk-chkstk.s<br>
> > +; RUN: llvm-ar cru %t.lib %T/lto-chkstk-chkstk.obj<br>
> > +; RUN: lld -flavor link2 /out:%t.exe /entry:main /subsystem:console<br>
> > %t.obj %T/lto-chkstk-foo.obj %t.lib<br>
> > +<br>
> > +target datalayout = "e-m:w-i64:64-f80:128-n8:16:32:64-S128"<br>
> > +target triple = "x86_64-pc-windows-msvc"<br>
> > +<br>
> > +define void @main() {<br>
> > +entry:<br>
> > + %array4096 = alloca [4096 x i8]<br>
> > + call void @foo([4096 x i8]* %array4096)<br>
> > + ret void<br>
> > +}<br>
> > +<br>
> > +declare void @foo([4096 x i8]*)<br>
> ><br>
> > EMAIL PREFERENCES<br>
> > <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_settings_panel_emailpreferences_&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=mQ4LZ2PUj9hpadE3cDHZnIdEwhEBrbAstXeMaFoB9tg&m=DT-WWK7K6eSG96IvwWPf58IjaRgLimTTo-A7U1Ub-Gs&s=MQ4nGJXA9v4VtQpg4nGxYxQkcIIf8tQFRq_aEX1wOXk&e=" target="_blank">http://reviews.llvm.org/settings/panel/emailpreferences/</a><br>
> ><br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
Peter<br>
<br>
_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
</font></span></blockquote></div><br></div></div>