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

Fri Feb 15 22:26:02 PST 2019

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 <mailto: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 <mailto: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 <mailto:cfe-dev at lists.llvm.org>> wrote:
>>> 
>>> Hi Peter,
>>> 
>>> On Feb 6, 2019, at 2:57 AM, Peter Smith <peter.smith at linaro.org <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto:cfe-dev at lists.llvm.org>
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev <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/b8e07726/attachment.html>