<div dir="ltr"><div></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 25, 2019 at 12:12 AM Eric Fiselier <<a href="mailto:eric@efcs.ca">eric@efcs.ca</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">Does `-nodefaultlibs` drop the library?</div></blockquote><div><br></div><div>The only difference between -nostdlib and -nodefaultlibs is whether you get start files or not (i.e. crt1.o, crtbegin.o, crtend.o, crtn.o).<br></div><div> </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>Within libc++, it's been quite useful to assume -fsanitize=foo opts you into the required libraries despite passing `-nostdlib` </div><div>(It only does this on some platforms). Because, at the moment, correctly re-building the compiler-rt link line is all but impossible.</div></div></blockquote><div><br></div><div>It sounds like a dedicated flag might be preferable to have a more flexibility.</div><div> </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>Whatever decision we make, let's make it consistent across platforms?</div></div></blockquote><div><br></div><div>I completely agree with that.</div><div> </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>/Eric</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jun 23, 2019 at 8:50 PM Petr Hosek via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-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">We're trying to enable profile instrumentation in our kernel. We would<br>
like to use -fprofile-instr-generate to enable the instrumentation,<br>
but provide our own runtime instead of the one that's part of<br>
compiler-rt which isn't compatible with the kernel environment.<br>
However, there's no way to tell the driver to avoid linking the<br>
runtime. This is the case not only for profile runtime, but for other<br>
runtimes like XRay or sanitizers as well.<br>
<br>
-nostdlib already controls whether system libraries are being linked<br>
into binary. Furthermore, when compiler-rt builtins are being used, it<br>
also controls whether those are being linked as well. This is somewhat<br>
inconsistent with other compiler runtimes mentioned above.<br>
<br>
Two potential solutions I came up with are:<br>
<br>
1. Change -nostdlib to affect linking of runtime libraries. This would<br>
make it consistent with the behavior it has when using compiler-rt<br>
builtins. However, it would also make it inconsistent with GCC, e.g.<br>
when you use --coverage -nostdlib, GCC would still pass -lgcov to the<br>
linker.<br>
<br>
2. Introduce a new flag, e.g. -nortlib, that would control linking of<br>
runtime libraries, including compiler-rt builtins.<br>
<br>
Do you have any opinion on this or any other suggestions?<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div>
</blockquote></div></div>