> 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
