[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?
> 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
>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-commits