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

Eric Fiselier eric at efcs.ca
Fri Oct 17 14:53:06 PDT 2014


> 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.


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20141017/6f672394/attachment.html>


More information about the cfe-commits mailing list