[cfe-dev] RFC: New clang option to force linking libclang_rt.a

Fri Feb 15 23:34:11 PST 2019

GCC implements -nolibc which could be used to achieve the same effect when
combined with -nostartfiles (and -nostdlib++ when compiling C++). I'd
prefer that approach not only because it improves compatibility with with
GCC, but also because it matches existing flag scheme which is subtractive
rather than additive (i.e. -nodefaultlibs, -nostdlib, -nostdlib++,
-nostartfiles). Clang already defines
<https://github.com/llvm/llvm-project/blob/master/clang/include/clang/Driver/Options.td#L2455>
this flag but the only toolchain that currently supports it is DragonFly
<https://github.com/llvm/llvm-project/blob/master/clang/lib/Driver/ToolChains/DragonFly.cpp#L137>
.

On Fri, Feb 15, 2019 at 10:26 PM Amara Emerson via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> Patch for review at: https://reviews.llvm.org/D58320
>
> Thanks,
> Amara
>
> On Feb 15, 2019, at 2:47 PM, Amara Emerson via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
>
> On Feb 15, 2019, at 9:17 AM, Peter Smith <peter.smith at linaro.org> wrote:
>
> I don't have a lot more to add, I've put some comments inline:
>
> On Thu, 14 Feb 2019 at 21:58, Amara Emerson <aemerson at apple.com> wrote:
>
>
> Ping. Any more thoughts on this option?
>
> Amara
>
> On Feb 6, 2019, at 10:59 AM, Amara Emerson via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
> Hi Peter,
>
> On Feb 6, 2019, at 2:57 AM, Peter Smith <peter.smith at linaro.org> wrote:
>
> Hello Amara,
>
> Given the amount of possible names, sometimes target dependent, that
> libclang_rt can take I think the current situation is unfriendly
> enough to do something about it.
>
> The GCC equivalent solution to this is -print-libgcc-file-name
> From the man page:
> "-print-libgcc-file-name
>         Same as -print-file-name=libgcc.a.
>
>         This is useful when you use -nostdlib or -nodefaultlibs but
> you do want to link with libgcc.a.  You can do:
>
>                 gcc -nostdlib <files>... `gcc -print-libgcc-file-name`
> "
>
> Would it be worth coming up with a similar solution in clang?
>
> As Petr says, this exists already. My proposal is to have a more user
> friendly option that doesn’t require a separation invocation. The issue
> with using that technique for me is that you have to specify all the
> necessary options in order to get the exact same path to the runtime lib as
> you would get in the link invocation. The driver already has the
> information available to it, so it seems a waste to have to specify it
> twice.
>
> OK, I can see that not requiring a second tool invocation would be a
> benefit.
>
>
> Some other questions:
> - On Linux there is not a single libclang_rt.a, but many separate ones
> like ./clang/9.0.0/lib/linux/libclang_rt.builtins-x86_64.a would this
> option be just the builtins?
>
> This is somewhat case as well on Darwin too, I just omitted the variants
> for brevity. For example, we have libclang_rt.ios.a and libclang_rt.osx.a,
> which are fat archives containing multiple architecture libs inside. Point
> being there’s no single libclang_rt.a file, we have logic in the driver to
> select the right variant to link. As to your question on whether this would
> be just the builtins, I would say yes. The intended use case for this
> option is to link in the runtime which the compiler needs as a necessary
> part of it’s codegen. I don’t intend to link anything else like asan
> runtimes. Because of that, perhaps a more obvious name like
> “-flink-builtin-rt” might be better? I don’t know.
>
> Thanks for the clarification. I personally prefer making the name
> specific to the builtins, but I'm aware that compiler-rt is split up
> that way. I don't know whether many users will though. Not got a
> strong opinion.
>
> - Would this extend to libgcc on linux? I don't know enough about
> Windows to know about an equivalent?
>
> I would only implement this on Darwin for now, but in theory yes. I think
> libgcc’s divide routines for example are necessary for armv7, but if you
> try to use -nostdlib with a linux target you’d run into the same problem.
>
> A pity, this could be useful on linux and embedded systems.
>
> - A possible alternative is that the presence of --rtlib=<library> is
> sufficient to add the -l even if --nodefaultlib etc. are added.
>
> I thought about that. It’s possible but I would rather not change the
> existing behaviour of options unless consensus is that it’s a good idea.
> With a new option there’s no risk of breaking existing code. The other
> thing with that is it seems like it could be interpreted as config option
> rather than a link option. E.g. maybe there are cases that option could be
> used to specify the *names* of symbols to use for particular runtime
> functionality, but without prescribing the implementation. It’s a niche
> corner case that I don’t know is realistic I admit.
>
> Fair enough.
>
>
> Peter
>
> Thanks for the feedback. I’ll post a patch for review to add the option
> under the name -flink-builtin-rt
>
> Amara
>
>
>
> On Tue, 5 Feb 2019 at 22:53, Duncan Exon Smith via cfe-dev
> <cfe-dev at lists.llvm.org> wrote:
>
>
> +cfe-dev, bcc: llvm-dev, since you're talking about changes to Clang.
>
> On 2019 Feb  5, at 14:43, Amara Emerson <aemerson at apple.com> wrote:
>
> Hi all,
>
> As far as I’m aware, there’s no way to specify to the clang driver at link
> time that you want to link in libclang_rt.a even in the presence of
> -nostdlib or -nodefaultlib. This behavior can be desirable in some cases as
> users may want to avoid linking libc++ or libSystem.dylib for example, but
> still want to have the compiler’s own builtin routines available. Since we
> view compiler-rt as an intricately linked (no pun intended) part of the
> overall compiler toolchain, I think this is a reasonable request.
>
> I’m proposing a new driver option to trigger this behaviour: -flink-rtlib
>
> Thoughts?
>
> Thanks,
> Amara
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
> _______________________________________________
> 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/20190215/3c26f78c/attachment.html>