Re: RFC: New clang option to force linking libclang_rt.a

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: RFC: New clang option to force linking libclang_rt.a

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

> On 2019 Feb  5, at 14:43, Amara Emerson <[hidden email]> 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
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC: New clang option to force linking libclang_rt.a

Ilya Biryukov via cfe-dev
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

On Tue, 5 Feb 2019 at 22:53, Duncan Exon Smith via cfe-dev
<[hidden email]> wrote:

>
> +cfe-dev, bcc: llvm-dev, since you're talking about changes to Clang.
>
> > On 2019 Feb  5, at 14:43, Amara Emerson <[hidden email]> 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
> [hidden email]
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC: New clang option to force linking libclang_rt.a

Ilya Biryukov via cfe-dev
On Wed, Feb 6, 2019 at 2:57 AM Peter Smith via cfe-dev <[hidden email]> 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?

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

On Tue, 5 Feb 2019 at 22:53, Duncan Exon Smith via cfe-dev
<[hidden email]> wrote:
>
> +cfe-dev, bcc: llvm-dev, since you're talking about changes to Clang.
>
> > On 2019 Feb  5, at 14:43, Amara Emerson <[hidden email]> 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
> [hidden email]
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC: New clang option to force linking libclang_rt.a

Ilya Biryukov via cfe-dev
In reply to this post by Ilya Biryukov via cfe-dev
Hi Peter,

> On Feb 6, 2019, at 2:57 AM, Peter Smith <[hidden email]> 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
> <[hidden email]> wrote:
>>
>> +cfe-dev, bcc: llvm-dev, since you're talking about changes to Clang.
>>
>>> On 2019 Feb  5, at 14:43, Amara Emerson <[hidden email]> 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
>> [hidden email]
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC: New clang option to force linking libclang_rt.a

Ilya Biryukov via cfe-dev
Ping. Any more thoughts on this option?

Amara

On Feb 6, 2019, at 10:59 AM, Amara Emerson via cfe-dev <[hidden email]> wrote:

Hi Peter,

On Feb 6, 2019, at 2:57 AM, Peter Smith <[hidden email]> 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
<[hidden email]> wrote:

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

On 2019 Feb  5, at 14:43, Amara Emerson <[hidden email]> 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
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC: New clang option to force linking libclang_rt.a

Ilya Biryukov via cfe-dev
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 <[hidden email]> wrote:

>
> Ping. Any more thoughts on this option?
>
> Amara
>
> On Feb 6, 2019, at 10:59 AM, Amara Emerson via cfe-dev <[hidden email]> wrote:
>
> Hi Peter,
>
> On Feb 6, 2019, at 2:57 AM, Peter Smith <[hidden email]> 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

>
> On Tue, 5 Feb 2019 at 22:53, Duncan Exon Smith via cfe-dev
> <[hidden email]> wrote:
>
>
> +cfe-dev, bcc: llvm-dev, since you're talking about changes to Clang.
>
> On 2019 Feb  5, at 14:43, Amara Emerson <[hidden email]> 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
> [hidden email]
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC: New clang option to force linking libclang_rt.a

Ilya Biryukov via cfe-dev

On Feb 15, 2019, at 9:17 AM, Peter Smith <[hidden email]> 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 <[hidden email]> wrote:

Ping. Any more thoughts on this option?

Amara

On Feb 6, 2019, at 10:59 AM, Amara Emerson via cfe-dev <[hidden email]> wrote:

Hi Peter,

On Feb 6, 2019, at 2:57 AM, Peter Smith <[hidden email]> 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
<[hidden email]> wrote:


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

On 2019 Feb  5, at 14:43, Amara Emerson <[hidden email]> 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
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC: New clang option to force linking libclang_rt.a

Ilya Biryukov via cfe-dev
Patch for review at: https://reviews.llvm.org/D58320

Thanks,
Amara

On Feb 15, 2019, at 2:47 PM, Amara Emerson via cfe-dev <[hidden email]> wrote:


On Feb 15, 2019, at 9:17 AM, Peter Smith <[hidden email]> 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 <[hidden email]> wrote:

Ping. Any more thoughts on this option?

Amara

On Feb 6, 2019, at 10:59 AM, Amara Emerson via cfe-dev <[hidden email]> wrote:

Hi Peter,

On Feb 6, 2019, at 2:57 AM, Peter Smith <[hidden email]> 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
<[hidden email]> wrote:


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

On 2019 Feb  5, at 14:43, Amara Emerson <[hidden email]> 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
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC: New clang option to force linking libclang_rt.a

Ilya Biryukov via cfe-dev
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.

On Fri, Feb 15, 2019 at 10:26 PM Amara Emerson via cfe-dev <[hidden email]> 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 <[hidden email]> wrote:


On Feb 15, 2019, at 9:17 AM, Peter Smith <[hidden email]> 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 <[hidden email]> wrote:

Ping. Any more thoughts on this option?

Amara

On Feb 6, 2019, at 10:59 AM, Amara Emerson via cfe-dev <[hidden email]> wrote:

Hi Peter,

On Feb 6, 2019, at 2:57 AM, Peter Smith <[hidden email]> 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
<[hidden email]> wrote:


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

On 2019 Feb  5, at 14:43, Amara Emerson <[hidden email]> 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
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC: New clang option to force linking libclang_rt.a

Ilya Biryukov via cfe-dev
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 <[hidden email]> 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 this flag but the only toolchain that currently supports it is DragonFly.

On Fri, Feb 15, 2019 at 10:26 PM Amara Emerson via cfe-dev <[hidden email]> 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 <[hidden email]> wrote:


On Feb 15, 2019, at 9:17 AM, Peter Smith <[hidden email]> 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 <[hidden email]> wrote:

Ping. Any more thoughts on this option?

Amara

On Feb 6, 2019, at 10:59 AM, Amara Emerson via cfe-dev <[hidden email]> wrote:

Hi Peter,

On Feb 6, 2019, at 2:57 AM, Peter Smith <[hidden email]> 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
<[hidden email]> wrote:


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

On 2019 Feb  5, at 14:43, Amara Emerson <[hidden email]> 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
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC: New clang option to force linking libclang_rt.a

Ilya Biryukov via cfe-dev
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 <[hidden email]> 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 <[hidden email]> 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 this flag but the only toolchain that currently supports it is DragonFly.

On Fri, Feb 15, 2019 at 10:26 PM Amara Emerson via cfe-dev <[hidden email]> 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 <[hidden email]> wrote:


On Feb 15, 2019, at 9:17 AM, Peter Smith <[hidden email]> 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 <[hidden email]> wrote:

Ping. Any more thoughts on this option?

Amara

On Feb 6, 2019, at 10:59 AM, Amara Emerson via cfe-dev <[hidden email]> wrote:

Hi Peter,

On Feb 6, 2019, at 2:57 AM, Peter Smith <[hidden email]> 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
<[hidden email]> wrote:


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

On 2019 Feb  5, at 14:43, Amara Emerson <[hidden email]> 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
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC: New clang option to force linking libclang_rt.a

Ilya Biryukov via cfe-dev
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 this flag but the only toolchain that currently supports it is DragonFly.

On Fri, Feb 15, 2019 at 10:26 PM Amara Emerson via cfe-dev <[hidden email]> 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 <[hidden email]> wrote:


On Feb 15, 2019, at 9:17 AM, Peter Smith <[hidden email]> 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 <[hidden email]> wrote:

Ping. Any more thoughts on this option?

Amara

On Feb 6, 2019, at 10:59 AM, Amara Emerson via cfe-dev <[hidden email]> wrote:

Hi Peter,

On Feb 6, 2019, at 2:57 AM, Peter Smith <[hidden email]> 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
<[hidden email]> wrote:


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

On 2019 Feb  5, at 14:43, Amara Emerson <[hidden email]> 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
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC: New clang option to force linking libclang_rt.a

Ilya Biryukov 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 this flag but the only toolchain that currently supports it is DragonFly.

On Fri, Feb 15, 2019 at 10:26 PM Amara Emerson via cfe-dev <[hidden email]> 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 <[hidden email]> wrote:


On Feb 15, 2019, at 9:17 AM, Peter Smith <[hidden email]> 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 <[hidden email]> wrote:

Ping. Any more thoughts on this option?

Amara

On Feb 6, 2019, at 10:59 AM, Amara Emerson via cfe-dev <[hidden email]> wrote:

Hi Peter,

On Feb 6, 2019, at 2:57 AM, Peter Smith <[hidden email]> 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
<[hidden email]> wrote:


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

On 2019 Feb  5, at 14:43, Amara Emerson <[hidden email]> 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
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC: New clang option to force linking libclang_rt.a

Ilya Biryukov via cfe-dev
Ah, I didn’t know we had that option. I think that would work.

Thanks,
Amara
On Feb 20, 2019, at 12:24 AM, Petr Hosek <[hidden email]> wrote:

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

On Fri, Feb 15, 2019 at 10:26 PM Amara Emerson via cfe-dev <[hidden email]> 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 <[hidden email]> wrote:


On Feb 15, 2019, at 9:17 AM, Peter Smith <[hidden email]> 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 <[hidden email]> wrote:

Ping. Any more thoughts on this option?

Amara

On Feb 6, 2019, at 10:59 AM, Amara Emerson via cfe-dev <[hidden email]> wrote:

Hi Peter,

On Feb 6, 2019, at 2:57 AM, Peter Smith <[hidden email]> 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
<[hidden email]> wrote:


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

On 2019 Feb  5, at 14:43, Amara Emerson <[hidden email]> 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
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev



_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC: New clang option to force linking libclang_rt.a

Ilya Biryukov via cfe-dev
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

On Feb 20, 2019, at 12:53 AM, Amara Emerson via cfe-dev <[hidden email]> wrote:

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

Thanks,
Amara
On Feb 20, 2019, at 12:24 AM, Petr Hosek <[hidden email]> wrote:

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

On Fri, Feb 15, 2019 at 10:26 PM Amara Emerson via cfe-dev <[hidden email]> 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 <[hidden email]> wrote:


On Feb 15, 2019, at 9:17 AM, Peter Smith <[hidden email]> 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 <[hidden email]> wrote:

Ping. Any more thoughts on this option?

Amara

On Feb 6, 2019, at 10:59 AM, Amara Emerson via cfe-dev <[hidden email]> wrote:

Hi Peter,

On Feb 6, 2019, at 2:57 AM, Peter Smith <[hidden email]> 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
<[hidden email]> wrote:


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

On 2019 Feb  5, at 14:43, Amara Emerson <[hidden email]> 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
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev