Should -nostdlib control runtime libraries?

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

Should -nostdlib control runtime libraries?

Nathan Ridge via cfe-dev
We're trying to enable profile instrumentation in our kernel. We would
like to use -fprofile-instr-generate to enable the instrumentation,
but provide our own runtime instead of the one that's part of
compiler-rt which isn't compatible with the kernel environment.
However, there's no way to tell the driver to avoid linking the
runtime. This is the case not only for profile runtime, but for other
runtimes like XRay or sanitizers as well.

-nostdlib already controls whether system libraries are being linked
into binary. Furthermore, when compiler-rt builtins are being used, it
also controls whether those are being linked as well. This is somewhat
inconsistent with other compiler runtimes mentioned above.

Two potential solutions I came up with are:

1. Change -nostdlib to affect linking of runtime libraries. This would
make it consistent with the behavior it has when using compiler-rt
builtins. However, it would also make it inconsistent with GCC, e.g.
when you use --coverage -nostdlib, GCC would still pass -lgcov to the
linker.

2. Introduce a new flag, e.g. -nortlib, that would control linking of
runtime libraries, including compiler-rt builtins.

Do you have any opinion on this or any other suggestions?
_______________________________________________
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: Should -nostdlib control runtime libraries?

Nathan Ridge via cfe-dev
Does `-nodefaultlibs` drop the library?

Within libc++, it's been quite useful to assume -fsanitize=foo opts you into the required libraries despite passing `-nostdlib` 
(It only does this on some platforms). Because, at the moment, correctly re-building the compiler-rt link line is all but impossible.

Whatever decision we make, let's make it consistent across platforms?

/Eric


On Sun, Jun 23, 2019 at 8:50 PM Petr Hosek via cfe-dev <[hidden email]> wrote:
We're trying to enable profile instrumentation in our kernel. We would
like to use -fprofile-instr-generate to enable the instrumentation,
but provide our own runtime instead of the one that's part of
compiler-rt which isn't compatible with the kernel environment.
However, there's no way to tell the driver to avoid linking the
runtime. This is the case not only for profile runtime, but for other
runtimes like XRay or sanitizers as well.

-nostdlib already controls whether system libraries are being linked
into binary. Furthermore, when compiler-rt builtins are being used, it
also controls whether those are being linked as well. This is somewhat
inconsistent with other compiler runtimes mentioned above.

Two potential solutions I came up with are:

1. Change -nostdlib to affect linking of runtime libraries. This would
make it consistent with the behavior it has when using compiler-rt
builtins. However, it would also make it inconsistent with GCC, e.g.
when you use --coverage -nostdlib, GCC would still pass -lgcov to the
linker.

2. Introduce a new flag, e.g. -nortlib, that would control linking of
runtime libraries, including compiler-rt builtins.

Do you have any opinion on this or any other suggestions?
_______________________________________________
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: Should -nostdlib control runtime libraries?

Nathan Ridge via cfe-dev
On Tue, Jun 25, 2019 at 12:12 AM Eric Fiselier <[hidden email]> wrote:
Does `-nodefaultlibs` drop the library?

The only difference between -nostdlib and -nodefaultlibs is whether you get start files or not (i.e. crt1.o, crtbegin.o, crtend.o, crtn.o).
 
Within libc++, it's been quite useful to assume -fsanitize=foo opts you into the required libraries despite passing `-nostdlib` 
(It only does this on some platforms). Because, at the moment, correctly re-building the compiler-rt link line is all but impossible.

It sounds like a dedicated flag might be preferable to have a more flexibility.
 
Whatever decision we make, let's make it consistent across platforms?

I completely agree with that.
 
/Eric


On Sun, Jun 23, 2019 at 8:50 PM Petr Hosek via cfe-dev <[hidden email]> wrote:
We're trying to enable profile instrumentation in our kernel. We would
like to use -fprofile-instr-generate to enable the instrumentation,
but provide our own runtime instead of the one that's part of
compiler-rt which isn't compatible with the kernel environment.
However, there's no way to tell the driver to avoid linking the
runtime. This is the case not only for profile runtime, but for other
runtimes like XRay or sanitizers as well.

-nostdlib already controls whether system libraries are being linked
into binary. Furthermore, when compiler-rt builtins are being used, it
also controls whether those are being linked as well. This is somewhat
inconsistent with other compiler runtimes mentioned above.

Two potential solutions I came up with are:

1. Change -nostdlib to affect linking of runtime libraries. This would
make it consistent with the behavior it has when using compiler-rt
builtins. However, it would also make it inconsistent with GCC, e.g.
when you use --coverage -nostdlib, GCC would still pass -lgcov to the
linker.

2. Introduce a new flag, e.g. -nortlib, that would control linking of
runtime libraries, including compiler-rt builtins.

Do you have any opinion on this or any other suggestions?
_______________________________________________
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