On Mon, Oct 20, 2014 at 2:43 PM, Eric Fiselier <[email protected]> wrote: > Hi All, > > 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. > Would anybody be able to offer advice as to how to properly link the > static sanitizer libraries? >
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. Or are you talking about adding one more flag to force linking in sanitizer runtimes? > > /Eric > > On Sat, Oct 18, 2014 at 12:06 PM, Eric Fiselier <[email protected]> wrote: > >> > 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)? >> >> That would be one way to solve the problem and probably a good approach. >> I would rather have flags that force the libraries to be linked even in >> the presence of '-nodefaultlibs'. >> It seems somewhat odd that GCC ignores -static-libgcc with -nodefaultlibs. >> >> Either way, with this new behavior there are going to be some growing >> pains, but that is our problem. >> >> On Fri, Oct 17, 2014 at 5:38 PM, Alexey Samsonov <[email protected]> >> wrote: >> >>> >>> On Fri, Oct 17, 2014 at 2:53 PM, Eric Fiselier <[email protected]> wrote: >>> >>>> > 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. >>>> >>>> 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. >>>> 1. As mentioned repeatedly, it isn't always possible to configure c++ >>>> projects so they only use -fsanitize when compiling and not linking. >>>> 2. There is a need for a way to remove the default sanitizer libraries. >>>> 3. GCC also removes the sanitizer libraries when -fsanitize and >>>> -nodefaultlibs are given. >>>> >>>> > 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. >>>> 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 >>>> some arguments, instead of linking with libc++ and libc++abi manually), >>>> and make usage of libc++/libc++abi easier for end user. >>>> >>>> I'm currently working on patching the clang driver to better handle >>>> linking against libc++ and its many ABI libraries. >>>> 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. >>>> >>>> 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. >>>> 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. >>>> >>> >>> 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)? >>> >>> >>>> >>>> Thanks for your time >>>> /Eric >>>> >>>> >>>> On Fri, Oct 17, 2014 at 3:24 PM, Alexey Samsonov <[email protected]> >>>> wrote: >>>> >>>>> >>>>> On Fri, Oct 17, 2014 at 1:11 PM, Filipe Cabecinhas <[email protected]> >>>>> wrote: >>>>> >>>>>> I don't know anything about the go compiler, but it seems to me this >>>>>> patch shouldn't be done like this. >>>>>> >>>>>> 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. >>>>>> >>>>> >>>>> -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". >>>>> >>>>>> >>>>>> >>>>> >>>>>> 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? >>>>>> >>>>> >>>>> 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. >>>>> >>>>> >>>>>> >>>>>> Regards, >>>>>> >>>>>> Filipe >>>>>> >>>>>> >>>>>> On Friday, October 17, 2014, Eric Fiselier <[email protected]> wrote: >>>>>> >>>>>>> Hi All, >>>>>>> >>>>>>> The libc++ LIT test driver uses -nodefaultlibs so that it can >>>>>>> properly link against libc++ and the ABI library. >>>>>>> >>>>>> >>>>> 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. >>>>> 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 >>>>> some arguments, instead of linking with libc++ and libc++abi >>>>> manually), and make usage of libc++/libc++abi easier for end user. >>>>> >>>>> >>>>>> 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. >>>>>>> >>>>>>> I agree with the rational behind your change. >>>>>>> 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. >>>>>>> I think we should consider adding '-static-lib*san' flags similar to >>>>>>> the ones provided by GCC. >>>>>>> >>>>>>> I'm not very knowledgeable about the clang linker driver so any >>>>>>> input is welcome. >>>>>>> >>>>>>> /Eric >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, Sep 26, 2014 at 3:22 PM, Alexey Samsonov <[email protected] >>>>>>> > wrote: >>>>>>> >>>>>>>> Author: samsonov >>>>>>>> Date: Fri Sep 26 16:22:08 2014 >>>>>>>> New Revision: 218541 >>>>>>>> >>>>>>>> URL: http://llvm.org/viewvc/llvm-project?rev=218541&view=rev >>>>>>>> Log: >>>>>>>> Don't link in sanitizer runtimes if -nostdlib/-nodefaultlibs is >>>>>>>> provided. >>>>>>>> >>>>>>>> It makes no sense to link in sanitizer runtimes in this case: the >>>>>>>> user >>>>>>>> probably doesn't want to see any system/toolchain libs in his link >>>>>>>> if he >>>>>>>> provides these flags, and the link will most likely fail anyway - >>>>>>>> as sanitizer >>>>>>>> runtimes depend on libpthread, libdl, libc etc. >>>>>>>> >>>>>>>> Also, see discussion in >>>>>>>> https://code.google.com/p/address-sanitizer/issues/detail?id=344 >>>>>>>> >>>>>>>> Modified: >>>>>>>> cfe/trunk/lib/Driver/Tools.cpp >>>>>>>> cfe/trunk/test/Driver/sanitizer-ld.c >>>>>>>> >>>>>>>> Modified: cfe/trunk/lib/Driver/Tools.cpp >>>>>>>> URL: >>>>>>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?rev=218541&r1=218540&r2=218541&view=diff >>>>>>>> >>>>>>>> ============================================================================== >>>>>>>> --- cfe/trunk/lib/Driver/Tools.cpp (original) >>>>>>>> +++ cfe/trunk/lib/Driver/Tools.cpp Fri Sep 26 16:22:08 2014 >>>>>>>> @@ -2243,6 +2243,10 @@ collectSanitizerRuntimes(const ToolChain >>>>>>>> // C runtime, etc). Returns true if sanitizer system deps need to >>>>>>>> be linked in. >>>>>>>> static bool addSanitizerRuntimes(const ToolChain &TC, const >>>>>>>> ArgList &Args, >>>>>>>> ArgStringList &CmdArgs) { >>>>>>>> + // Don't link in any sanitizer runtimes if we have no system >>>>>>>> libraries. >>>>>>>> + if (Args.hasArg(options::OPT_nostdlib) || >>>>>>>> + Args.hasArg(options::OPT_nodefaultlibs)) >>>>>>>> + return false; >>>>>>>> SmallVector<StringRef, 4> SharedRuntimes, StaticRuntimes, >>>>>>>> HelperStaticRuntimes; >>>>>>>> collectSanitizerRuntimes(TC, Args, SharedRuntimes, >>>>>>>> StaticRuntimes, >>>>>>>> >>>>>>>> Modified: cfe/trunk/test/Driver/sanitizer-ld.c >>>>>>>> URL: >>>>>>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/sanitizer-ld.c?rev=218541&r1=218540&r2=218541&view=diff >>>>>>>> >>>>>>>> ============================================================================== >>>>>>>> --- cfe/trunk/test/Driver/sanitizer-ld.c (original) >>>>>>>> +++ cfe/trunk/test/Driver/sanitizer-ld.c Fri Sep 26 16:22:08 2014 >>>>>>>> @@ -301,3 +301,10 @@ >>>>>>>> // CHECK-LSAN-ASAN-LINUX-NOT: libclang_rt.lsan >>>>>>>> // CHECK-LSAN-ASAN-LINUX: libclang_rt.asan-x86_64 >>>>>>>> // CHECK-LSAN-ASAN-LINUX-NOT: libclang_rt.lsan >>>>>>>> + >>>>>>>> +// RUN: %clang -nostdlib -fsanitize=address %s -### -o %t.o 2>&1 \ >>>>>>>> +// RUN: -target x86_64-unknown-linux \ >>>>>>>> +// RUN: --sysroot=%S/Inputs/basic_linux_tree \ >>>>>>>> +// RUN: | FileCheck --check-prefix=CHECK-NOSTDLIB %s >>>>>>>> +// CHECK-NOSTDLIB: "{{.*}}ld{{(.exe)?}}" >>>>>>>> +// CHECK-NOSTDLIB-NOT: libclang_rt.asan >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> cfe-commits mailing list >>>>>>>> [email protected] >>>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits >>>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>>>> -- >>>>> Alexey Samsonov >>>>> [email protected] >>>>> >>>> >>>> >>> >>> >>> -- >>> Alexey Samsonov >>> [email protected] >>> >> >> > -- Alexey Samsonov [email protected]
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
