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

Eric Fiselier eric at efcs.ca
Mon Oct 20 14:43:28 PDT 2014 

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 <eric at efcs.ca> 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 <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/20141020/2eab07ff/attachment.html>

More information about the cfe-commits mailing list