Sorry I was being stupid and had the static sanitizer libraries after some dynamic ones which caused some linker errors. Do they need to be wrapped in -whole-archive/-no-whole-archive? Do I also need to pass the '--dynamic-list' flags?
Although I got the tests working, getting the CMake build to add the proper libraries is going to be a lot more difficult. I would implore you to consider a solution that shifts the work onto the compiler. /Eric On Mon, Oct 20, 2014 at 5:31 PM, Alexey Samsonov <[email protected]> wrote: > > 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
