r218541 - Don't link in sanitizer runtimes if -nostdlib/-nodefaultlibs is provided.

Eric Fiselier eric at efcs.ca
Sat Oct 18 11:06:31 PDT 2014 

> 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 <vonosmas at gmail.com> wrote:

>
> On Fri, Oct 17, 2014 at 2:53 PM, Eric Fiselier <eric at efcs.ca> 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 <vonosmas at gmail.com>
>> wrote:
>>
>>>
>>> On Fri, Oct 17, 2014 at 1:11 PM, Filipe Cabecinhas <filcab at filcab.net>
>>> 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 <eric at efcs.ca> 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 <vonosmas at gmail.com>
>>>>> 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
>>>>>> cfe-commits at cs.uiuc.edu
>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>>>>>>
>>>>>
>>>>>
>>>
>>>
>>> --
>>> Alexey Samsonov
>>> vonosmas at gmail.com
>>>
>>
>>
>
>
> --
> Alexey Samsonov
> vonosmas at gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20141018/ddb6b8c8/attachment.html>

More information about the cfe-commits mailing list