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

Tue Feb 19 20:27:03 PST 2019

I think Petr's point is that the user can pass -nolibc *instead* of passing
-nostdlib, if they want to include libgcc/compiler-rt but not
libc/libSystem.

On Tue, Feb 19, 2019 at 7:36 PM Amara Emerson via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> I don’t think that option still achieves what we want here. We want a way
> to force linking even when -nostdlib is given. At the moment, -nostdlib
> causes Darwin, and from the looks of it, Dragonfly too, to completely skip
> over any runtime linking. So implementing -nolibc doesn’t help here, as you
> say it’s a subtractive option.
>
> -nostdlib and -nodefaultlibs are the real issue here. Unless we change
> what those options do, which I’m not confident of doing for every target
> and platform. And changing just Darwin’s interpretation of -nostdlib isn’t
> ideal either.
>
> Amara
>
> On Feb 15, 2019, at 11:34 PM, Petr Hosek <phosek at chromium.org> wrote:
>
> 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
>>
>
> _______________________________________________
> 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/20190219/c964b173/attachment.html>