RFC: New clang option to force linking libclang_rt.a

Project Infrastructure LLVM Dev List Archives
1

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

2

+cfe-dev, bcc: llvm-dev, since you're talking about changes to Clang.

3

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?

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?
- Would this extend to libgcc on linux? I don't know enough about
Windows to know about an equivalent?
- A possible alternative is that the presence of --rtlib=<library> is
sufficient to add the -l even if --nodefaultlib etc. are added.

Peter

4

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 … gcc -print-libgcc-file-name
"

Would it be worth coming up with a similar solution in clang?

This is already supported in Clang, we also use this solution in the CMake build for libunwind, libc++abi, libc++ and compiler-rt to find out the location of builtins (since all these libraries are being built with -nodefaultlibs), see for example https://github.com/llvm/llvm-project/blob/master/compiler-rt/cmake/Modules/HandleCompilerRT.cmake#L3

5

Hi Peter,

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.

6

Ping. Any more thoughts on this option?

Amara

7

I don't have a lot more to add, I've put some comments inline:

Ping. Any more thoughts on this option?

Amara

Hi Peter,

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

8

I don’t have a lot more to add, I’ve put some comments inline:

Ping. Any more thoughts on this option?

Amara

Hi Peter,

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 … 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= 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

9

Patch for review at: https://reviews.llvm.org/D58320

Thanks,
Amara

10

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 this flag but the only toolchain that currently supports it is DragonFly.

11

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

12

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.

13

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.

14

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

15

Ah, I didn’t know we had that option. I think that would work.

Thanks,
Amara

16

Actually, I don’t think this would work completely for Darwin because the driver currently disables all runtime lib linking with -static. In order to support linking the runtimes even in the presence of -static I think we need a new option, but because this is problem only affects Darwin I’ll introduce it as an Apple-specific flag.

Thanks,
Amara