<div dir="ltr">What are the thoughts about going back to linking the static analyzer library and adding a different flag that allows you to drop it?<div>For example '-nosanitizerruntime'.</div><div><br></div><div>/Eric</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 20, 2014 at 7:29 PM, Alexey Samsonov <span dir="ltr"><<a href="mailto:vonosmas@gmail.com" target="_blank">vonosmas@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Mon, Oct 20, 2014 at 5:01 PM, Eric Fiselier <span dir="ltr"><<a href="mailto:eric@efcs.ca" target="_blank">eric@efcs.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">That works for me, but isn't that the old behavior? </div></blockquote><div><br></div></span><div>It almost is. Unfortunately, we've seen the cases where -nodefaultlibs is the only reasonable discriminator which distinguishes linking actual executable from manual linking of relocatable</div><div>file (unless we go and parse flags passed to linker in -Wl, which we certainly don't want to do), so it's not dynamic system libraries that cause the problem, it's sanitizer runtime,</div><div>which should only be linked once into the final executable, not intermediate files.</div><div><br></div><div>But I agree it's kind of messed up, and it's questionable we can treat sanitizer runtimes as "system" libraries.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span><font color="#888888"><div><br></div><div>/Eric</div></font></span></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 20, 2014 at 5:53 PM, Filipe Cabecinhas <span dir="ltr"><<a href="mailto:me@filcab.net" target="_blank">me@filcab.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I still don't like that -fsanitize=undefined doesn't bring the sanitizer *.a files. They're not default libs for any classification that I can come up with, they're being explicitly linked in.<div><br></div><div>What about this:</div><div><br></div><div>If both are specified (-fsanitize=blah, and -nodefault libs), then -fsanitize=blah will only pull in the static sanitizer library, but not its dependencies (-lc, -lpthread, etc), since those _could_ be understood as "default libs". It will be up to the user to figure out how to get those symbols (by passing additional linker options), since they have to be available at runtime.</div><div><br></div><div>That way, we're following "the spirit of" both flags.</div><div><br></div><div>gcc's manual says:</div><div><div>-nodefaultlibs</div><div>Do not use the standard system libraries when linking. Only the libraries you specify are passed to the linker, and options specifying linkage of the system libraries, such as -static-libgcc or -shared-libgcc, are ignored. The standard startup files are used normally, unless -nostartfiles is used.</div></div><div><br></div><div>With that description, it makes total sense that -static-libgcc is ignored. It's not that -nodefaultlibs "wins" over it. It's that -static-libgcc says "if linking with libgcc, use the static version”.</div></div></blockquote></div></div></div></div></blockquote><div><br></div></span><div>I agree, and "-nodefaultlibs" implies "don't link with libgcc".</div><div><div class="h5"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>What do you think about this option?</div><div>This makes us not have to figure out, outside of clang, where the sanitizer libs are, and makes those -nodefaultlibs cases understandable (and not pull in libraries you weren't expecting).</div></div></blockquote></div></div></div></div></blockquote><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Thanks,</div><div><br></div><div> Filipe</div><div><br></div><div><br></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 20, 2014 at 4:37 PM, Eric Fiselier <span dir="ltr"><<a href="mailto:eric@efcs.ca" target="_blank">eric@efcs.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Sorry I was being stupid and had the static sanitizer libraries after some dynamic ones which caused some linker errors.<div>Do they need to be wrapped in -whole-archive/-no-whole-archive? Do I also need to pass the '--dynamic-list' flags?</div><div><br></div><div>Although I got the tests working, getting the CMake build to add the proper libraries is going to be a lot more difficult.</div><div>I would implore you to consider a solution that shifts the work onto the compiler.</div><span><font color="#888888"><div><br></div><div>/Eric</div></font></span></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 20, 2014 at 5:31 PM, Alexey Samsonov <span dir="ltr"><<a href="mailto:vonosmas@gmail.com" target="_blank">vonosmas@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote"><span>On Mon, Oct 20, 2014 at 2:43 PM, Eric Fiselier <span dir="ltr"><<a href="mailto:eric@efcs.ca" target="_blank">eric@efcs.ca</a>></span> wrote:<br></span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi All,<div><br></div><span><div>I've spent some time trying to work around this. I probe clang to find the libclang_rt libraries but I cant seem to link them correctly.<br></div><div>Would anybody be able to offer advice as to how to properly link the static sanitizer libraries?</div></span></div></blockquote><div><br></div><div>What do you mean? If you know the location of sanitizer runtimes, you can just add them to linker invocation, possibly wrapped in -whole-archive/-no-whole-archive.</div><div>Or are you talking about adding one more flag to force linking in sanitizer runtimes?</div><div><div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span><font color="#888888"><div><br></div><div>/Eric</div></font></span></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Oct 18, 2014 at 12:06 PM, Eric Fiselier <span dir="ltr"><<a href="mailto:eric@efcs.ca" target="_blank">eric@efcs.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span><span style="font-family:arial,sans-serif;font-size:13px">> Would it help if we teach the Clang driver to print the path to sanitizer runtime libraries (smth. like GCC's -print-libgcc-file-name flag)?<div><br></div></span></span><div style="font-family:arial,sans-serif;font-size:13px">That would be one way to solve the problem and probably a good approach.</div><div style="font-family:arial,sans-serif;font-size:13px">I would rather have flags that force the libraries to be linked even in the presence of '-nodefaultlibs'. </div><div style="font-family:arial,sans-serif;font-size:13px">It seems somewhat odd that GCC ignores -static-libgcc with -nodefaultlibs.</div><div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px"><font face="arial, sans-serif">Either way, with this new behavior there are going to be some growing pains, but that is our problem.</font></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 17, 2014 at 5:38 PM, Alexey Samsonov <span dir="ltr"><<a href="mailto:vonosmas@gmail.com" target="_blank">vonosmas@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote"><span>On Fri, Oct 17, 2014 at 2:53 PM, Eric Fiselier <span dir="ltr"><<a href="mailto:eric@efcs.ca" target="_blank">eric@efcs.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span><span style="font-size:13px;font-family:arial,sans-serif">> If I understand correctly, when you pass -fsanitize=undefined (or whatever) to the linker job, all it does is add the library. If this is correct, then it makes no sense to have -nodefaultlibs remove it: it's not a default lib and it was explicitly added by passing -fsanitize to the link job.</span><br><div><br></div></span><div>I agree. It seems to me your asking for the library to be linked in explicitly. However I think the current behavior is acceptable as well. A couple of salient points.</div><div>1. As mentioned repeatedly, it isn't always possible to configure c++ projects so they only use -fsanitize when compiling and not linking.</div><div>2. There is a need for a way to remove the default sanitizer libraries.</div><div>3. GCC also removes the sanitizer libraries when -fsanitize and -nodefaultlibs are given.</div><span><div><br></div><div>> <span style="font-family:arial,sans-serif;font-size:13px">Why can't we link with libc++ using -stdlib=libc++ flag? Linking against libc++abi instead of (not "in addition to") libsupc++ (or whatever) might be challenging, though.</span></div><div style="font-family:arial,sans-serif;font-size:13px">However, I think it would really make sense to add support for this configuration to Clang driver. It would make your LIT configs simpler (you'll just invoke the Clang with</div><div style="font-family:arial,sans-serif;font-size:13px">some arguments, instead of linking with libc++ and libc++abi manually), and make usage of libc++/libc++abi easier for end user.</div><div style="font-family:arial,sans-serif;font-size:13px"><br></div></span><div style="font-family:arial,sans-serif;font-size:13px">I'm currently working on patching the clang driver to better handle linking against libc++ and its many ABI libraries. </div><div style="font-family:arial,sans-serif;font-size:13px">It will take some work before this approach is viable for testing libc++, and even when it is viable older compilers and GCC will still have to be supported separately. </div><div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">Currently the libc++ test suite handles linking the required libraries works with both GCC and Clang. It is generic and flexible across a wide range of compilers, platforms and ABI library combinations.</div><div style="font-family:arial,sans-serif;font-size:13px">Changing the way we set up the tests to deal with this will require a fair amount of work and a ton of special cases. I'll look into what we can do to make the change.</div></div></blockquote><div><br></div></span><div>Would it help if we teach the Clang driver to print the path to sanitizer runtime libraries (smth. like GCC's -print-libgcc-file-name flag)?</div><div><div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px"><br></div><div>Thanks for your time</div><span><font color="#888888"><div>/Eric</div><div><br></div></font></span></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 17, 2014 at 3:24 PM, Alexey Samsonov <span dir="ltr"><<a href="mailto:vonosmas@gmail.com" target="_blank">vonosmas@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote"><span>On Fri, Oct 17, 2014 at 1:11 PM, Filipe Cabecinhas <span dir="ltr"><<a href="mailto:filcab@filcab.net" target="_blank">filcab@filcab.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I don't know anything about the go compiler, but it seems to me this patch shouldn't be done like this.<div><br></div><div>If I understand correctly, when you pass -fsanitize=undefined (or whatever) to the linker job, all it does is add the library. If this is correct, then it makes no sense to have -nodefaultlibs remove it: it's not a default lib and it was explicitly added by passing -fsanitize to the link job.</div></blockquote><div><br></div></span><div>-fsanitize=whatever not only adds the static sanitizer runtime library, but also pulls in its dependencies on system libraries (-lc, -ldl, -lpthread, -lrt). It would be weird to add these libraries if the user explicitly specified -nodefaultlibs. Generally, it's ok to make this flag win other flags, adding libraries explicitly. For example, GCC manual specifies that "-static-libgcc" is ignored in presence of "-nodefaultlibs".</div><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div> </div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><span></span></div><div><br></div><div>From what's in the bug report, isn't it possible to change go's behaviour by passing it -fsanitize=blah in CFLAGS but now passing it in LDFLAGS, since it will add it by itself?</div></blockquote><div><br></div></span><div>Not really, it's hard to fix the build system in your project if it builds 10 binaries with LDFLAGS, and 10 more targets with "LDFLAGS + -nodefaultlibs + ...".It's nice if the driver is able to handle it automatically and discard the irrelevant flags in the second case.</div><span><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br></div><div>Regards,</div><div><br></div><div> Filipe<div><div><br><br>On Friday, October 17, 2014, Eric Fiselier <<a href="mailto:eric@efcs.ca" target="_blank">eric@efcs.ca</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi All,<div><br></div><div>The libc++ LIT test driver uses -nodefaultlibs so that it can properly link against libc++ and the ABI library.</div></div></blockquote></div></div></div></blockquote><div><br></div></span><div>Why can't we link with libc++ using -stdlib=libc++ flag? Linking against libc++abi instead of (not "in addition to") libsupc++ (or whatever) might be challenging, though.</div><div>However, I think it would really make sense to add support for this configuration to Clang driver. It would make your LIT configs simpler (you'll just invoke the Clang with</div><div>some arguments, instead of linking with libc++ and libc++abi manually), and make usage of libc++/libc++abi easier for end user.</div><div><div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Since this patch we can no longer use sanitizers when running our test suite since it's quite difficult to mimic the driver's behavior and manually link in the sanitizer runtimes.</div><div><br></div><div>I agree with the rational behind your change. </div><div>However, since it's difficult to manually link the sanitizer runtimes, it would be nice to have a way to force the front end to do it even when -nodefaultlibs is present.</div><div>I think we should consider adding '-static-lib*san' flags similar to the ones provided by GCC.<br></div><div><br></div><div>I'm not very knowledgeable about the clang linker driver so any input is welcome. </div><div><br></div><div>/Eric</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 26, 2014 at 3:22 PM, Alexey Samsonov <span dir="ltr"><<a>vonosmas@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Author: samsonov<br>
Date: Fri Sep 26 16:22:08 2014<br>
New Revision: 218541<br>
<br>
URL: <a href="http://llvm.org/viewvc/llvm-project?rev=218541&view=rev" target="_blank">http://llvm.org/viewvc/llvm-project?rev=218541&view=rev</a><br>
Log:<br>
Don't link in sanitizer runtimes if -nostdlib/-nodefaultlibs is provided.<br>
<br>
It makes no sense to link in sanitizer runtimes in this case: the user<br>
probably doesn't want to see any system/toolchain libs in his link if he<br>
provides these flags, and the link will most likely fail anyway - as sanitizer<br>
runtimes depend on libpthread, libdl, libc etc.<br>
<br>
Also, see discussion in <a href="https://code.google.com/p/address-sanitizer/issues/detail?id=344" target="_blank">https://code.google.com/p/address-sanitizer/issues/detail?id=344</a><br>
<br>
Modified:<br>
cfe/trunk/lib/Driver/Tools.cpp<br>
cfe/trunk/test/Driver/sanitizer-ld.c<br>
<br>
Modified: cfe/trunk/lib/Driver/Tools.cpp<br>
URL: <a href="http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?rev=218541&r1=218540&r2=218541&view=diff" target="_blank">http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?rev=218541&r1=218540&r2=218541&view=diff</a><br>
==============================================================================<br>
--- cfe/trunk/lib/Driver/Tools.cpp (original)<br>
+++ cfe/trunk/lib/Driver/Tools.cpp Fri Sep 26 16:22:08 2014<br>
@@ -2243,6 +2243,10 @@ collectSanitizerRuntimes(const ToolChain<br>
// C runtime, etc). Returns true if sanitizer system deps need to be linked in.<br>
static bool addSanitizerRuntimes(const ToolChain &TC, const ArgList &Args,<br>
ArgStringList &CmdArgs) {<br>
+ // Don't link in any sanitizer runtimes if we have no system libraries.<br>
+ if (Args.hasArg(options::OPT_nostdlib) ||<br>
+ Args.hasArg(options::OPT_nodefaultlibs))<br>
+ return false;<br>
SmallVector<StringRef, 4> SharedRuntimes, StaticRuntimes,<br>
HelperStaticRuntimes;<br>
collectSanitizerRuntimes(TC, Args, SharedRuntimes, StaticRuntimes,<br>
<br>
Modified: cfe/trunk/test/Driver/sanitizer-ld.c<br>
URL: <a href="http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/sanitizer-ld.c?rev=218541&r1=218540&r2=218541&view=diff" target="_blank">http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/sanitizer-ld.c?rev=218541&r1=218540&r2=218541&view=diff</a><br>
==============================================================================<br>
--- cfe/trunk/test/Driver/sanitizer-ld.c (original)<br>
+++ cfe/trunk/test/Driver/sanitizer-ld.c Fri Sep 26 16:22:08 2014<br>
@@ -301,3 +301,10 @@<br>
// CHECK-LSAN-ASAN-LINUX-NOT: libclang_rt.lsan<br>
// CHECK-LSAN-ASAN-LINUX: libclang_rt.asan-x86_64<br>
// CHECK-LSAN-ASAN-LINUX-NOT: libclang_rt.lsan<br>
+<br>
+// RUN: %clang -nostdlib -fsanitize=address %s -### -o %t.o 2>&1 \<br>
+// RUN: -target x86_64-unknown-linux \<br>
+// RUN: --sysroot=%S/Inputs/basic_linux_tree \<br>
+// RUN: | FileCheck --check-prefix=CHECK-NOSTDLIB %s<br>
+// CHECK-NOSTDLIB: "{{.*}}ld{{(.exe)?}}"<br>
+// CHECK-NOSTDLIB-NOT: libclang_rt.asan<br>
<br>
<br>
_______________________________________________<br>
cfe-commits mailing list<br>
<a>cfe-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits</a><br>
</blockquote></div><br></div>
</blockquote></div></div></div>
</blockquote></div></div></div><span><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Alexey Samsonov<br><a href="mailto:vonosmas@gmail.com" target="_blank">vonosmas@gmail.com</a></div>
</font></span></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div></div></div><span><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Alexey Samsonov<br><a href="mailto:vonosmas@gmail.com" target="_blank">vonosmas@gmail.com</a></div>
</font></span></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div></div></div><span><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Alexey Samsonov<br><a href="mailto:vonosmas@gmail.com" target="_blank">vonosmas@gmail.com</a></div>
</font></span></div></div>
</blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
cfe-commits mailing list<br>
<a href="mailto:cfe-commits@cs.uiuc.edu" target="_blank">cfe-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits</a><br>
<br></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div></div></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Alexey Samsonov<br><a href="mailto:vonosmas@gmail.com" target="_blank">vonosmas@gmail.com</a></div>
</font></span></div></div>
</blockquote></div><br></div>