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

[Amara Emerson via cfe-dev]

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.
> 
> 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.
> - 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 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.
> 
> Peter
> 
> 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