Under some circumstances, the compiler generates .ctors.* sections. This
is seen doing a cross compile of x86_64 from a powerpc64el host:
x86_64-linux-gnu-ld: warning: orphan section `.ctors.65435' from `kernel/trace/trace_clock.o' being
placed in section `.ctors.65435'
x86_64-linux-gnu-ld: warning: orphan section `.ctors.65435' from `kernel/trace/ftrace.o' being
placed in section `.ctors.65435'
x86_64-linux-gnu-ld: warning: orphan section `.ctors.65435' from `kernel/trace/ring_buffer.o' being
placed in section `.ctors.65435'
Include these orphans along with the regular .ctors section.
Reported-by: Stephen Rothwell <[email protected]>
Tested-by: Stephen Rothwell <[email protected]>
Fixes: 83109d5d5fba ("x86/build: Warn on orphan section placement")
Signed-off-by: Kees Cook <[email protected]>
---
v2: brown paper bag version: fix whitespace for proper backslash alignment
---
include/asm-generic/vmlinux.lds.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index 5430febd34be..b83c00c63997 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -684,6 +684,7 @@
#ifdef CONFIG_CONSTRUCTORS
#define KERNEL_CTORS() . = ALIGN(8); \
__ctors_start = .; \
+ KEEP(*(SORT(.ctors.*))) \
KEEP(*(.ctors)) \
KEEP(*(SORT(.init_array.*))) \
KEEP(*(.init_array)) \
--
2.25.1
On Sun, Oct 4, 2020 at 7:57 PM Kees Cook <[email protected]> wrote:
>
> Under some circumstances, the compiler generates .ctors.* sections. This
> is seen doing a cross compile of x86_64 from a powerpc64el host:
>
> x86_64-linux-gnu-ld: warning: orphan section `.ctors.65435' from `kernel/trace/trace_clock.o' being
> placed in section `.ctors.65435'
> x86_64-linux-gnu-ld: warning: orphan section `.ctors.65435' from `kernel/trace/ftrace.o' being
> placed in section `.ctors.65435'
> x86_64-linux-gnu-ld: warning: orphan section `.ctors.65435' from `kernel/trace/ring_buffer.o' being
> placed in section `.ctors.65435'
>
> Include these orphans along with the regular .ctors section.
It's very curious to see different behavior based on whether one is
targeting x86_64 via native compilation vs cross compilation.
Acked-by: Nick Desaulniers <[email protected]>
>
> Reported-by: Stephen Rothwell <[email protected]>
> Tested-by: Stephen Rothwell <[email protected]>
> Fixes: 83109d5d5fba ("x86/build: Warn on orphan section placement")
> Signed-off-by: Kees Cook <[email protected]>
> ---
> v2: brown paper bag version: fix whitespace for proper backslash alignment
> ---
> include/asm-generic/vmlinux.lds.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
> index 5430febd34be..b83c00c63997 100644
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -684,6 +684,7 @@
> #ifdef CONFIG_CONSTRUCTORS
> #define KERNEL_CTORS() . = ALIGN(8); \
> __ctors_start = .; \
> + KEEP(*(SORT(.ctors.*))) \
> KEEP(*(.ctors)) \
> KEEP(*(SORT(.init_array.*))) \
> KEEP(*(.init_array)) \
> --
> 2.25.1
>
--
Thanks,
~Nick Desaulniers
On Wed, Oct 14, 2020 at 4:04 PM Kees Cook <[email protected]> wrote:
>
> On Sun, Oct 04, 2020 at 07:57:20PM -0700, Kees Cook wrote:
> > Under some circumstances, the compiler generates .ctors.* sections. This
> > is seen doing a cross compile of x86_64 from a powerpc64el host:
> >
> > x86_64-linux-gnu-ld: warning: orphan section `.ctors.65435' from `kernel/trace/trace_clock.o' being
> > placed in section `.ctors.65435'
> > x86_64-linux-gnu-ld: warning: orphan section `.ctors.65435' from `kernel/trace/ftrace.o' being
> > placed in section `.ctors.65435'
> > x86_64-linux-gnu-ld: warning: orphan section `.ctors.65435' from `kernel/trace/ring_buffer.o' being
> > placed in section `.ctors.65435'
> >
> > Include these orphans along with the regular .ctors section.
> >
> > Reported-by: Stephen Rothwell <[email protected]>
> > Tested-by: Stephen Rothwell <[email protected]>
> > Fixes: 83109d5d5fba ("x86/build: Warn on orphan section placement")
> > Signed-off-by: Kees Cook <[email protected]>
>
> Ping -- please take this for tip/urgent, otherwise we're drowning sfr in
> warnings. :)
>
> -Kees
>
> > ---
> > v2: brown paper bag version: fix whitespace for proper backslash alignment
> > ---
> > include/asm-generic/vmlinux.lds.h | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
> > index 5430febd34be..b83c00c63997 100644
> > --- a/include/asm-generic/vmlinux.lds.h
> > +++ b/include/asm-generic/vmlinux.lds.h
> > @@ -684,6 +684,7 @@
> > #ifdef CONFIG_CONSTRUCTORS
> > #define KERNEL_CTORS() . = ALIGN(8); \
> > __ctors_start = .; \
> > + KEEP(*(SORT(.ctors.*))) \
> > KEEP(*(.ctors)) \
> > KEEP(*(SORT(.init_array.*))) \
> > KEEP(*(.init_array)) \
> > --
> > 2.25.1
> >
>
> --
> Kees Cook
>
> --
> You received this message because you are subscribed to the Google Groups "Clang Built Linux" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
> To view this discussion on the web visit https://groups.google.com/d/msgid/clang-built-linux/202010141603.49EA0CE%40keescook.
I think it would be great to figure out why these .ctors.* .dtors.*
are generated.
~GCC 4.7 switched to default to .init_array/.fini_array if libc
supports it. I have some refactoring in this area of Clang as well
(e.g. https://reviews.llvm.org/D71393)
And I am not sure SORT(.init_array.*) or SORT(.ctors.*) will work. The
correct construct is SORT_BY_INIT_PRIORITY(.init_array.*)
On Sun, Oct 04, 2020 at 07:57:20PM -0700, Kees Cook wrote:
> Under some circumstances, the compiler generates .ctors.* sections. This
> is seen doing a cross compile of x86_64 from a powerpc64el host:
>
> x86_64-linux-gnu-ld: warning: orphan section `.ctors.65435' from `kernel/trace/trace_clock.o' being
> placed in section `.ctors.65435'
> x86_64-linux-gnu-ld: warning: orphan section `.ctors.65435' from `kernel/trace/ftrace.o' being
> placed in section `.ctors.65435'
> x86_64-linux-gnu-ld: warning: orphan section `.ctors.65435' from `kernel/trace/ring_buffer.o' being
> placed in section `.ctors.65435'
>
> Include these orphans along with the regular .ctors section.
>
> Reported-by: Stephen Rothwell <[email protected]>
> Tested-by: Stephen Rothwell <[email protected]>
> Fixes: 83109d5d5fba ("x86/build: Warn on orphan section placement")
> Signed-off-by: Kees Cook <[email protected]>
Ping -- please take this for tip/urgent, otherwise we're drowning sfr in
warnings. :)
-Kees
> ---
> v2: brown paper bag version: fix whitespace for proper backslash alignment
> ---
> include/asm-generic/vmlinux.lds.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
> index 5430febd34be..b83c00c63997 100644
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -684,6 +684,7 @@
> #ifdef CONFIG_CONSTRUCTORS
> #define KERNEL_CTORS() . = ALIGN(8); \
> __ctors_start = .; \
> + KEEP(*(SORT(.ctors.*))) \
> KEEP(*(.ctors)) \
> KEEP(*(SORT(.init_array.*))) \
> KEEP(*(.init_array)) \
> --
> 2.25.1
>
--
Kees Cook
On Wed, Oct 14, 2020 at 09:53:39PM -0700, Fāng-ruì Sòng wrote:
> On Wed, Oct 14, 2020 at 4:04 PM Kees Cook <[email protected]> wrote:
> > > index 5430febd34be..b83c00c63997 100644
> > > --- a/include/asm-generic/vmlinux.lds.h
> > > +++ b/include/asm-generic/vmlinux.lds.h
> > > @@ -684,6 +684,7 @@
> > > #ifdef CONFIG_CONSTRUCTORS
> > > #define KERNEL_CTORS() . = ALIGN(8); \
> > > __ctors_start = .; \
> > > + KEEP(*(SORT(.ctors.*))) \
> > > KEEP(*(.ctors)) \
> > > KEEP(*(SORT(.init_array.*))) \
> > > KEEP(*(.init_array)) \
> > > --
> > > 2.25.1
>
> I think it would be great to figure out why these .ctors.* .dtors.* are generated.
I haven't had the time to investigate. This patch keeps sfr's builds
from regressing, so we need at least this first.
> ~GCC 4.7 switched to default to .init_array/.fini_array if libc
> supports it. I have some refactoring in this area of Clang as well
> (e.g. https://reviews.llvm.org/D71393)
>
> And I am not sure SORT(.init_array.*) or SORT(.ctors.*) will work. The
> correct construct is SORT_BY_INIT_PRIORITY(.init_array.*)
The kernel doesn't seem to use the init_priority attribute at all. Are
you saying the cause of the .ctors.* names are a result of some internal
use of init_priority by the compiler here?
--
Kees Cook
[thread ping: x86 maintainers, can someone please take this?]
On Sun, Oct 04, 2020 at 07:57:20PM -0700, Kees Cook wrote:
> Under some circumstances, the compiler generates .ctors.* sections. This
> is seen doing a cross compile of x86_64 from a powerpc64el host:
>
> x86_64-linux-gnu-ld: warning: orphan section `.ctors.65435' from `kernel/trace/trace_clock.o' being
> placed in section `.ctors.65435'
> x86_64-linux-gnu-ld: warning: orphan section `.ctors.65435' from `kernel/trace/ftrace.o' being
> placed in section `.ctors.65435'
> x86_64-linux-gnu-ld: warning: orphan section `.ctors.65435' from `kernel/trace/ring_buffer.o' being
> placed in section `.ctors.65435'
>
> Include these orphans along with the regular .ctors section.
>
> Reported-by: Stephen Rothwell <[email protected]>
> Tested-by: Stephen Rothwell <[email protected]>
> Fixes: 83109d5d5fba ("x86/build: Warn on orphan section placement")
> Signed-off-by: Kees Cook <[email protected]>
> ---
> v2: brown paper bag version: fix whitespace for proper backslash alignment
> ---
> include/asm-generic/vmlinux.lds.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
> index 5430febd34be..b83c00c63997 100644
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -684,6 +684,7 @@
> #ifdef CONFIG_CONSTRUCTORS
> #define KERNEL_CTORS() . = ALIGN(8); \
> __ctors_start = .; \
> + KEEP(*(SORT(.ctors.*))) \
> KEEP(*(.ctors)) \
> KEEP(*(SORT(.init_array.*))) \
> KEEP(*(.init_array)) \
> --
> 2.25.1
>
--
Kees Cook
On Wed, Oct 21, 2020 at 1:09 PM Kees Cook <[email protected]> wrote:
>
> On Wed, Oct 14, 2020 at 09:53:39PM -0700, Fāng-ruì Sòng wrote:
> > On Wed, Oct 14, 2020 at 4:04 PM Kees Cook <[email protected]> wrote:
> > > > index 5430febd34be..b83c00c63997 100644
> > > > --- a/include/asm-generic/vmlinux.lds.h
> > > > +++ b/include/asm-generic/vmlinux.lds.h
> > > > @@ -684,6 +684,7 @@
> > > > #ifdef CONFIG_CONSTRUCTORS
> > > > #define KERNEL_CTORS() . = ALIGN(8); \
> > > > __ctors_start = .; \
> > > > + KEEP(*(SORT(.ctors.*))) \
> > > > KEEP(*(.ctors)) \
> > > > KEEP(*(SORT(.init_array.*))) \
> > > > KEEP(*(.init_array)) \
> > > > --
> > > > 2.25.1
> >
> > I think it would be great to figure out why these .ctors.* .dtors.* are generated.
>
> I haven't had the time to investigate. This patch keeps sfr's builds
> from regressing, so we need at least this first.
We need to know under what circumstances .ctors.* are generated.
For Clang>=10.0.1, for all *-linux triples, .init_array/.finit_array
are used by default.
There is a toggle -fno-use-init-array (not in GCC) to switch back to
.ctors/.dtors
Modern GCC also uses .init_array. The minimum requirement is now GCC
4.9 and thus I wonder whether the .ctors configuration is still
supported.
If it is (maybe because glibc version which is not specified on
https://www.kernel.org/doc/html/latest/process/changes.html ), we
should use
some #if to highlight that.
> > ~GCC 4.7 switched to default to .init_array/.fini_array if libc
> > supports it. I have some refactoring in this area of Clang as well
> > (e.g. https://reviews.llvm.org/D71393)
> >
> > And I am not sure SORT(.init_array.*) or SORT(.ctors.*) will work. The
> > correct construct is SORT_BY_INIT_PRIORITY(.init_array.*)
>
> The kernel doesn't seem to use the init_priority attribute at all. Are
> you saying the cause of the .ctors.* names are a result of some internal
> use of init_priority by the compiler here?
>
If no priority is intended, consider deleting SORT to avoid confusion?
On Wed, Oct 21, 2020 at 01:04:35PM -0700, Kees Cook wrote:
> [thread ping: x86 maintainers, can someone please take this?]
$ ./scripts/get_maintainer.pl -f include/asm-generic/vmlinux.lds.h
Arnd Bergmann <[email protected]> (maintainer:GENERIC INCLUDE/ASM HEADER FILES)
...
so that's Arnd's AFAICT.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Thu, Oct 22, 2020 at 12:22:15AM +0200, Borislav Petkov wrote:
> On Wed, Oct 21, 2020 at 01:04:35PM -0700, Kees Cook wrote:
> > [thread ping: x86 maintainers, can someone please take this?]
>
> $ ./scripts/get_maintainer.pl -f include/asm-generic/vmlinux.lds.h
> Arnd Bergmann <[email protected]> (maintainer:GENERIC INCLUDE/ASM HEADER FILES)
> ...
>
> so that's Arnd's AFAICT.
It was a fix for the series Ingo took, so I seemed sensible to keep it
together. Though at this point, I don't care who takes it. :)
Arnd, do you have a tree that'll go to Linus before -rc1?
--
Kees Cook
On Wed, Oct 21, 2020 at 03:25:06PM -0700, Kees Cook wrote:
> It was a fix for the series Ingo took, so I seemed sensible to keep it
> together. Though at this point, I don't care who takes it. :)
That series is upstream already, I presume. And then it probably doesn't
matter who takes it...
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette