[cfe-dev] Should -nostdlib control runtime libraries?

[Eric Fiselier via cfe-dev]

Does `-nodefaultlibs` drop the library?

Within libc++, it's been quite useful to assume -fsanitize=foo opts you
into the required libraries despite passing `-nostdlib`
(It only does this on some platforms). Because, at the moment, correctly
re-building the compiler-rt link line is all but impossible.

Whatever decision we make, let's make it consistent across platforms?

/Eric


On Sun, Jun 23, 2019 at 8:50 PM Petr Hosek via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> We're trying to enable profile instrumentation in our kernel. We would
> like to use -fprofile-instr-generate to enable the instrumentation,
> but provide our own runtime instead of the one that's part of
> compiler-rt which isn't compatible with the kernel environment.
> However, there's no way to tell the driver to avoid linking the
> runtime. This is the case not only for profile runtime, but for other
> runtimes like XRay or sanitizers as well.
>
> -nostdlib already controls whether system libraries are being linked
> into binary. Furthermore, when compiler-rt builtins are being used, it
> also controls whether those are being linked as well. This is somewhat
> inconsistent with other compiler runtimes mentioned above.
>
> Two potential solutions I came up with are:
>
> 1. Change -nostdlib to affect linking of runtime libraries. This would
> make it consistent with the behavior it has when using compiler-rt
> builtins. However, it would also make it inconsistent with GCC, e.g.
> when you use --coverage -nostdlib, GCC would still pass -lgcov to the
> linker.
>
> 2. Introduce a new flag, e.g. -nortlib, that would control linking of
> runtime libraries, including compiler-rt builtins.
>
> Do you have any opinion on this or any other suggestions?
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190625/92291803/attachment.html>