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

[Petr Hosek via cfe-dev]

You can use the combination of -nolibc and -nostdlib++ to avoid linking
both libc and C++ standard library.

On Wed, Feb 20, 2019 at 12:18 AM Amara Emerson <aemerson at apple.com> wrote:

> I see. From the documentation, it explicitly doesn’t prevent libstdc++
> from being linked. So it doesn’t quite cover the same semantics as
> -nostdlib/-nodefaultlib + -flink-builtins-rt
>
> Now maybe you could argue that libstdc++ without a libc isn’t very useful
> so -nolibc should imply not linking libstdc++/libc++, but perhaps someone
> might want it just for language support but without having a libc on their
> system.
>
> On Feb 19, 2019, at 8:27 PM, James Y Knight <jyknight at google.com> wrote:
>
> 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/20190220/6a5f576f/attachment.html>