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

[Richard Smith via cfe-commits]

On Thu, Sep 8, 2016 at 11:19 AM, 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.


Ultimately, the clang driver should do whatever makes sense for Darwin when
targeting Darwin, and in this case perhaps being compatible with earlier
versions of the driver is the right thing. However, if we reach consensus
that the non-Darwin behavior is preferable, we do have reasonable options
to transition. For instance, we could change the driver to produce a
warning if -nodefaultlibs is enabled with a -fsanitize= flag, suggesting
adding -fno-sanitize=all to avoid linking the sanitizer runtimes, and then
after a release or two, change the behavior for that case to link the
sanitizer runtimes. We've done similar things for other changes to
sanitizer flags in the past and it's worked out pretty well. If we go that
way, we could add a -f flag to force linking the sanitizer runtime even
with -nodefaultlibs to tide libc++ over until the Darwin driver is brought
in line with our other modes. Likewise, if we decide that the current
Darwin behavior is preferable, we can transition the driver behavior for
non-Darwin targets in an analogous way.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20160908/923bd96b/attachment.html>