[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