[PATCH] D24048: [Driver] [Darwin] Add sanitizer libraries even if -nodefaultlibs is passed

Richard Smith via cfe-commits cfe-commits at lists.llvm.org
Thu Sep 8 14:17:40 PDT 2016


On Thu, Sep 8, 2016 at 12:06 PM, Filipe Cabecinhas <
filcab+llvm.phabricator at gmail.com> wrote:

> It seems some people on this thread (I'm sorry if everyone is taking this
> into account, but it seemed to me that this was going unnoticed, I want to
> make sure everyone is on the same page) is only talking about linking (or
> not) the sanitizer runtimes. But that's not the only thing.
>
> Depending on the OS, -fsanitize will also link in the sanitizer's
> dependencies, which might include libdl, libc++, and others.
>

I think this is actually consistent across OSs: on non-Darwin,
-nodefaultlibs turns off implicit linking of the sanitizer runtimes'
dependencies. On Darwin, there are no additional dependencies (the
sanitizer runtimes are linked as DSOs). Also, libc++ is not one of the
dependencies that we implicitly link due to -fsanitize. (Those are
-lpthread, -lrt, -lm, and sometimes -ldl.)

That was the reason why the patch was reverted last time we tried to change
> this flag's behavior: a sanitized libc++ needs the sanitizer libs, but not
> libc++... And it might need other dependencies for the sanitizers.
>
> Maybe have something like:
> -fsanitize=blah links all libs
> -fsanitize=blah -nodefaultlibs links nothing
> And then have two flags for explicitly linking either the sanitizer flag
> or the dependencies? Libc++ would still have the problem of wanting some
> dependencies but not all, though :-(
>

If the goal is to make it easier to link standard library implementations,
maybe instead we should add a -nodefaultlibs++, mirroring -nostdinc++, to
only remove the C++ standard library parts from the link and leave all
other implicit libs alone?

Thank you,
>
>  Filipe
>
> On Thursday, 8 September 2016, Anna Zaks <zaks.anna at gmail.com> wrote:
>
>> zaks.anna added a comment.
>>
>> > I don't see the point of adding another flag to control this when we
>> already have a perfectly good set of
>>
>> >  flags that already do the right thing -- that takes us three levels
>> deep in flags overriding the behavior of
>>
>> >  other flags, and I don't see how it actually helps our users in any
>> way.
>>
>>
>> Going with silently linking the sanitizer runtimes when -nostdlib is
>> passed will cause regressions in user experience. They will start getting
>> inexplicable run time failures instead of build failures. Which solution do
>> you propose to fix this problem?
>>
>> This specific situation comes up often on internal mailing lists, so we
>> should not go for a solution that regresses the behavior on Darwin.
>>
>>
>> https://reviews.llvm.org/D24048
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20160908/238235bc/attachment-0001.html>


More information about the cfe-commits mailing list