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

Fri Oct 17 16:38:14 PDT 2014

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/20141017/c9c1a775/attachment.html>