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?
/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] >> > >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
