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

[Filipe Cabecinhas via cfe-commits]

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

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/396451c3/attachment.html>