[PATCH] vmlinux.lds.h: Keep .ctors.* with .ctors

8 views
Skip to first unread message

Kees Cook

unread,
Oct 4, 2020, 10:52:55 PM10/4/20
to Ingo Molnar, Kees Cook, Stephen Rothwell, Nick Desaulniers, Arnd Bergmann, clang-bu...@googlegroups.com, linux...@vger.kernel.org, linux-...@vger.kernel.org
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 <s...@canb.auug.org.au>
Link: https://lore.kernel.org/lkml/20200914132...@canb.auug.org.au
Tested-by: Stephen Rothwell <s...@canb.auug.org.au>
Link: https://lore.kernel.org/lkml/20201004210...@canb.auug.org.au
Fixes: 83109d5d5fba ("x86/build: Warn on orphan section placement")
Signed-off-by: Kees Cook <kees...@chromium.org>
---
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..45c8b362ca45 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

unread,
Oct 4, 2020, 10:57:29 PM10/4/20
to Ingo Molnar, Kees Cook, Stephen Rothwell, Nick Desaulniers, Arnd Bergmann, clang-bu...@googlegroups.com, linux...@vger.kernel.org, linux-...@vger.kernel.org
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 <s...@canb.auug.org.au>
Tested-by: Stephen Rothwell <s...@canb.auug.org.au>
Fixes: 83109d5d5fba ("x86/build: Warn on orphan section placement")
Signed-off-by: Kees Cook <kees...@chromium.org>
---
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

Nick Desaulniers

unread,
Oct 5, 2020, 1:36:23 PM10/5/20
to Kees Cook, Ingo Molnar, Stephen Rothwell, Arnd Bergmann, clang-built-linux, linux-arch, LKML, linux-to...@vger.kernel.org, Segher Boessenkool
On Sun, Oct 4, 2020 at 7:57 PM Kees Cook <kees...@chromium.org> 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 <ndesau...@google.com>

>
> Reported-by: Stephen Rothwell <s...@canb.auug.org.au>
> Tested-by: Stephen Rothwell <s...@canb.auug.org.au>
> Fixes: 83109d5d5fba ("x86/build: Warn on orphan section placement")
> Signed-off-by: Kees Cook <kees...@chromium.org>
> ---
> 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

Kees Cook

unread,
Oct 14, 2020, 7:04:45 PM10/14/20
to Ingo Molnar, Stephen Rothwell, Nick Desaulniers, Arnd Bergmann, clang-bu...@googlegroups.com, linux...@vger.kernel.org, linux-...@vger.kernel.org, x...@kernel.org
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 <s...@canb.auug.org.au>
> Tested-by: Stephen Rothwell <s...@canb.auug.org.au>
> Fixes: 83109d5d5fba ("x86/build: Warn on orphan section placement")
> Signed-off-by: Kees Cook <kees...@chromium.org>

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

Fāng-ruì Sòng

unread,
Oct 15, 2020, 12:53:52 AM10/15/20
to Kees Cook, Ingo Molnar, Stephen Rothwell, Nick Desaulniers, Arnd Bergmann, clang-built-linux, linux-arch, LKML, X86 ML
> --
> 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 clang-built-li...@googlegroups.com.
> 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.*)

Kees Cook

unread,
Oct 21, 2020, 4:04:38 PM10/21/20
to Ingo Molnar, x...@kernel.org, Stephen Rothwell, Nick Desaulniers, Arnd Bergmann, clang-bu...@googlegroups.com, linux...@vger.kernel.org, linux-...@vger.kernel.org
[thread ping: x86 maintainers, can someone please take this?]

On Sun, Oct 04, 2020 at 07:57:20PM -0700, Kees Cook wrote:
--
Kees Cook

Kees Cook

unread,
Oct 21, 2020, 4:09:03 PM10/21/20
to Fāng-ruì Sòng, Ingo Molnar, Stephen Rothwell, Nick Desaulniers, Arnd Bergmann, clang-built-linux, linux-arch, LKML, X86 ML
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 <kees...@chromium.org> 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

Fāng-ruì Sòng

unread,
Oct 21, 2020, 4:32:21 PM10/21/20
to Kees Cook, Ingo Molnar, Stephen Rothwell, Nick Desaulniers, Arnd Bergmann, clang-built-linux, linux-arch, LKML, X86 ML
On Wed, Oct 21, 2020 at 1:09 PM Kees Cook <kees...@chromium.org> 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 <kees...@chromium.org> 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?

Borislav Petkov

unread,
Oct 21, 2020, 6:22:22 PM10/21/20
to Kees Cook, Ingo Molnar, x...@kernel.org, Stephen Rothwell, Nick Desaulniers, Arnd Bergmann, clang-bu...@googlegroups.com, linux...@vger.kernel.org, linux-...@vger.kernel.org
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 <ar...@arndb.de> (maintainer:GENERIC INCLUDE/ASM HEADER FILES)
...

so that's Arnd's AFAICT.

--
Regards/Gruss,
Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Kees Cook

unread,
Oct 21, 2020, 6:25:09 PM10/21/20
to Borislav Petkov, Arnd Bergmann, Ingo Molnar, x...@kernel.org, Stephen Rothwell, Nick Desaulniers, clang-bu...@googlegroups.com, linux...@vger.kernel.org, linux-...@vger.kernel.org
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 <ar...@arndb.de> (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

Borislav Petkov

unread,
Oct 21, 2020, 6:29:34 PM10/21/20
to Kees Cook, Arnd Bergmann, Ingo Molnar, x...@kernel.org, Stephen Rothwell, Nick Desaulniers, clang-bu...@googlegroups.com, linux...@vger.kernel.org, linux-...@vger.kernel.org
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.
Reply all
Reply to author
Forward
0 new messages