On Thu, Sep 8, 2016 at 12:06 PM, Filipe Cabecinhas < filcab+llvm.phabrica...@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.a...@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 >> >> >> >>
_______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
