* [RFC] Don't create sframes during build
@ 2025-09-04 13:18 Sebastian Andrzej Siewior
2025-09-04 14:02 ` Matthias Klose
0 siblings, 1 reply; 5+ messages in thread
From: Sebastian Andrzej Siewior @ 2025-09-04 13:18 UTC (permalink / raw)
To: linux-arch, linux-kernel, linux-kbuild
Cc: Arnd Bergmann, Josh Poimboeuf, Peter Zijlstra, Matthias Klose,
Nathan Chancellor, Nicolas Schier
Hi,
gcc in Debian, starting with 15.2.0-2, 14.3.0-6 enables sframe
generation. Unless options like -ffreestanding are passed. Since this
isn't done, there are a few warnings during compile
| crypto/chacha.o: warning: objtool: .sframe+0x30: data relocation to !ENDBR: chacha_stream_xor+0x0
| crypto/chacha.o: warning: objtool: .sframe+0x94: data relocation to !ENDBR: crypto_xchacha_crypt+0x0
followed by warnings at the end
| AR vmlinux.a
| LD vmlinux.o
| vmlinux.o: warning: objtool: .sframe+0x15c: data relocation to !ENDBR: repair_env_string+0x0
| vmlinux.o: warning: objtool: .sframe+0x1c0: data relocation to !ENDBR: run_init_process+0x0
| vmlinux.o: warning: objtool: .sframe+0x1d4: data relocation to !ENDBR: try_to_run_init_process+0x0
| vmlinux.o: warning: objtool: .sframe+0x1e8: data relocation to !ENDBR: rcu_read_unlock+0x0
…
| vmlinux.o: warning: objtool: .sframe+0x12765c: data relocation to !ENDBR: get_eff_addr_reg+0x0
| vmlinux.o: warning: objtool: .sframe+0x1276ac: data relocation to !ENDBR: get_seg_base_limit+0x0
| OBJCOPY modules.builtin.modinfo
followed by a boom
| LD .tmp_vmlinux1
| ld: error: unplaced orphan section `.sframe' from `vmlinux.o'
We could drop the sframe during the final link but this does not get rid
of the objtool warnings so we would have to ignore them. But we don't
need it. So what about the following:
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -886,6 +886,8 @@ ifdef CONFIG_CC_IS_GCC
KBUILD_CFLAGS += $(call cc-option,--param=allow-store-data-races=0)
KBUILD_CFLAGS += $(call cc-option,-fno-allow-store-data-races)
endif
+# No sframe generation for kernel if enabled by default
+KBUILD_CFLAGS += $(call cc-option,-Xassembler --gsframe=no)
ifdef CONFIG_READABLE_ASM
# Disable optimizations that make assembler listings hard to read.
--
2.51.0
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [RFC] Don't create sframes during build
2025-09-04 13:18 [RFC] Don't create sframes during build Sebastian Andrzej Siewior
@ 2025-09-04 14:02 ` Matthias Klose
2025-09-04 16:26 ` Matthias Klose
2025-09-04 16:34 ` Sebastian Andrzej Siewior
0 siblings, 2 replies; 5+ messages in thread
From: Matthias Klose @ 2025-09-04 14:02 UTC (permalink / raw)
To: Sebastian Andrzej Siewior, linux-arch, linux-kernel, linux-kbuild
Cc: Arnd Bergmann, Josh Poimboeuf, Peter Zijlstra, Nathan Chancellor,
Nicolas Schier, Binutils
[ CCing binutils@sourceware.org ]
On 9/4/25 15:18, Sebastian Andrzej Siewior wrote:
> Hi,
>
> gcc in Debian, starting with 15.2.0-2, 14.3.0-6 enables sframe
> generation. Unless options like -ffreestanding are passed. Since this
> isn't done, there are a few warnings during compile
If there are other options when sframe shouldn't be enabled, please tell.
Gentoo chose another approach, enabling sframe unconditionally in gas,
unless disabled by --gsframe=no.
> | crypto/chacha.o: warning: objtool: .sframe+0x30: data relocation to !ENDBR: chacha_stream_xor+0x0
> | crypto/chacha.o: warning: objtool: .sframe+0x94: data relocation to !ENDBR: crypto_xchacha_crypt+0x0
>
> followed by warnings at the end
>
> | AR vmlinux.a
> | LD vmlinux.o
> | vmlinux.o: warning: objtool: .sframe+0x15c: data relocation to !ENDBR: repair_env_string+0x0
> | vmlinux.o: warning: objtool: .sframe+0x1c0: data relocation to !ENDBR: run_init_process+0x0
> | vmlinux.o: warning: objtool: .sframe+0x1d4: data relocation to !ENDBR: try_to_run_init_process+0x0
> | vmlinux.o: warning: objtool: .sframe+0x1e8: data relocation to !ENDBR: rcu_read_unlock+0x0
> …
> | vmlinux.o: warning: objtool: .sframe+0x12765c: data relocation to !ENDBR: get_eff_addr_reg+0x0
> | vmlinux.o: warning: objtool: .sframe+0x1276ac: data relocation to !ENDBR: get_seg_base_limit+0x0
> | OBJCOPY modules.builtin.modinfo
>
> followed by a boom
> | LD .tmp_vmlinux1
> | ld: error: unplaced orphan section `.sframe' from `vmlinux.o'
>
> We could drop the sframe during the final link but this does not get rid
> of the objtool warnings so we would have to ignore them. But we don't
> need it. So what about the following:
>
> diff --git a/Makefile b/Makefile
> --- a/Makefile
> +++ b/Makefile
> @@ -886,6 +886,8 @@ ifdef CONFIG_CC_IS_GCC
> KBUILD_CFLAGS += $(call cc-option,--param=allow-store-data-races=0)
> KBUILD_CFLAGS += $(call cc-option,-fno-allow-store-data-races)
> endif
> +# No sframe generation for kernel if enabled by default
> +KBUILD_CFLAGS += $(call cc-option,-Xassembler --gsframe=no)
>
> ifdef CONFIG_READABLE_ASM
> # Disable optimizations that make assembler listings hard to read.
This is what I chose for package builds that need disablement of sframe.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [RFC] Don't create sframes during build
2025-09-04 14:02 ` Matthias Klose
@ 2025-09-04 16:26 ` Matthias Klose
2025-09-04 16:34 ` Sebastian Andrzej Siewior
1 sibling, 0 replies; 5+ messages in thread
From: Matthias Klose @ 2025-09-04 16:26 UTC (permalink / raw)
To: Sebastian Andrzej Siewior, linux-arch, linux-kernel, linux-kbuild
Cc: Arnd Bergmann, Josh Poimboeuf, Peter Zijlstra, Nathan Chancellor,
Nicolas Schier, Binutils
On 9/4/25 16:02, Matthias Klose wrote:
> [ CCing binutils@sourceware.org ]
>
> On 9/4/25 15:18, Sebastian Andrzej Siewior wrote:
>> Hi,
>>
>> gcc in Debian, starting with 15.2.0-2, 14.3.0-6 enables sframe
>> generation. Unless options like -ffreestanding are passed. Since this
>> isn't done, there are a few warnings during compile
>
> If there are other options when sframe shouldn't be enabled, please tell.
>
> Gentoo chose another approach, enabling sframe unconditionally in gas,
> unless disabled by --gsframe=no.
>
>> | crypto/chacha.o: warning: objtool: .sframe+0x30: data relocation
>> to !ENDBR: chacha_stream_xor+0x0
>> | crypto/chacha.o: warning: objtool: .sframe+0x94: data relocation
>> to !ENDBR: crypto_xchacha_crypt+0x0
>>
>> followed by warnings at the end
>>
>> | AR vmlinux.a
>> | LD vmlinux.o
>> | vmlinux.o: warning: objtool: .sframe+0x15c: data relocation to !
>> ENDBR: repair_env_string+0x0
>> | vmlinux.o: warning: objtool: .sframe+0x1c0: data relocation to !
>> ENDBR: run_init_process+0x0
>> | vmlinux.o: warning: objtool: .sframe+0x1d4: data relocation to !
>> ENDBR: try_to_run_init_process+0x0
>> | vmlinux.o: warning: objtool: .sframe+0x1e8: data relocation to !
>> ENDBR: rcu_read_unlock+0x0
>> …
>> | vmlinux.o: warning: objtool: .sframe+0x12765c: data relocation to !
>> ENDBR: get_eff_addr_reg+0x0
>> | vmlinux.o: warning: objtool: .sframe+0x1276ac: data relocation to !
>> ENDBR: get_seg_base_limit+0x0
>> | OBJCOPY modules.builtin.modinfo
>>
>> followed by a boom
>> | LD .tmp_vmlinux1
>> | ld: error: unplaced orphan section `.sframe' from `vmlinux.o'
>>
>> We could drop the sframe during the final link but this does not get rid
>> of the objtool warnings so we would have to ignore them. But we don't
>> need it. So what about the following:
>>
>> diff --git a/Makefile b/Makefile
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -886,6 +886,8 @@ ifdef CONFIG_CC_IS_GCC
>> KBUILD_CFLAGS += $(call cc-option,--param=allow-store-data-races=0)
>> KBUILD_CFLAGS += $(call cc-option,-fno-allow-store-data-races)
>> endif
>> +# No sframe generation for kernel if enabled by default
>> +KBUILD_CFLAGS += $(call cc-option,-Xassembler --gsframe=no)
>> ifdef CONFIG_READABLE_ASM
>> # Disable optimizations that make assembler listings hard to read.
> This is what I chose for package builds that need disablement of sframe.
Fyi, I will disable that again next week, until sframe v3 is ready.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [RFC] Don't create sframes during build
2025-09-04 14:02 ` Matthias Klose
2025-09-04 16:26 ` Matthias Klose
@ 2025-09-04 16:34 ` Sebastian Andrzej Siewior
2025-09-04 17:14 ` Josh Poimboeuf
1 sibling, 1 reply; 5+ messages in thread
From: Sebastian Andrzej Siewior @ 2025-09-04 16:34 UTC (permalink / raw)
To: Matthias Klose
Cc: linux-arch, linux-kernel, linux-kbuild, Arnd Bergmann,
Josh Poimboeuf, Peter Zijlstra, Nathan Chancellor, Nicolas Schier,
Binutils
On 2025-09-04 16:02:42 [+0200], Matthias Klose wrote:
> [ CCing binutils@sourceware.org ]
>
> On 9/4/25 15:18, Sebastian Andrzej Siewior wrote:
> > Hi,
> >
> > gcc in Debian, starting with 15.2.0-2, 14.3.0-6 enables sframe
> > generation. Unless options like -ffreestanding are passed. Since this
> > isn't done, there are a few warnings during compile
>
> If there are other options when sframe shouldn't be enabled, please tell.
No, I think this is okay.
…
> > We could drop the sframe during the final link but this does not get rid
> > of the objtool warnings so we would have to ignore them. But we don't
> > need it. So what about the following:
> >
> > diff --git a/Makefile b/Makefile
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -886,6 +886,8 @@ ifdef CONFIG_CC_IS_GCC
> > KBUILD_CFLAGS += $(call cc-option,--param=allow-store-data-races=0)
> > KBUILD_CFLAGS += $(call cc-option,-fno-allow-store-data-races)
> > endif
> > +# No sframe generation for kernel if enabled by default
> > +KBUILD_CFLAGS += $(call cc-option,-Xassembler --gsframe=no)
> > ifdef CONFIG_READABLE_ASM
> > # Disable optimizations that make assembler listings hard to read.
> This is what I chose for package builds that need disablement of sframe.
I think this would work for now. Longterm we would have to allow sframe
creation and keep section if an architecture decides to use it for its
backtracing. While orc seems fine on x86, there are arm64 patches to use
for as a stack unwinder.
Sebastian
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [RFC] Don't create sframes during build
2025-09-04 16:34 ` Sebastian Andrzej Siewior
@ 2025-09-04 17:14 ` Josh Poimboeuf
0 siblings, 0 replies; 5+ messages in thread
From: Josh Poimboeuf @ 2025-09-04 17:14 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: Matthias Klose, linux-arch, linux-kernel, linux-kbuild,
Arnd Bergmann, Peter Zijlstra, Nathan Chancellor, Nicolas Schier,
Binutils, Steven Rostedt
On Thu, Sep 04, 2025 at 06:34:04PM +0200, Sebastian Andrzej Siewior wrote:
> On 2025-09-04 16:02:42 [+0200], Matthias Klose wrote:
> > [ CCing binutils@sourceware.org ]
> >
> > On 9/4/25 15:18, Sebastian Andrzej Siewior wrote:
> > > Hi,
> > >
> > > gcc in Debian, starting with 15.2.0-2, 14.3.0-6 enables sframe
> > > generation. Unless options like -ffreestanding are passed. Since this
> > > isn't done, there are a few warnings during compile
> >
> > If there are other options when sframe shouldn't be enabled, please tell.
>
> No, I think this is okay.
>
> …
> > > We could drop the sframe during the final link but this does not get rid
> > > of the objtool warnings so we would have to ignore them. But we don't
> > > need it. So what about the following:
> > >
> > > diff --git a/Makefile b/Makefile
> > > --- a/Makefile
> > > +++ b/Makefile
> > > @@ -886,6 +886,8 @@ ifdef CONFIG_CC_IS_GCC
> > > KBUILD_CFLAGS += $(call cc-option,--param=allow-store-data-races=0)
> > > KBUILD_CFLAGS += $(call cc-option,-fno-allow-store-data-races)
> > > endif
> > > +# No sframe generation for kernel if enabled by default
> > > +KBUILD_CFLAGS += $(call cc-option,-Xassembler --gsframe=no)
> > > ifdef CONFIG_READABLE_ASM
> > > # Disable optimizations that make assembler listings hard to read.
> > This is what I chose for package builds that need disablement of sframe.
>
> I think this would work for now. Longterm we would have to allow sframe
> creation and keep section if an architecture decides to use it for its
> backtracing. While orc seems fine on x86, there are arm64 patches to use
> for as a stack unwinder.
This is probably fine, but... how does this interact with other kernel
makefiles enabling sframe? For example, x86 will soon have a patch to
enable sframe generation for vdso. And as you mentioned, arm64 will
enable it kernel-wide.
Removing the objtool !ENDBR warnings would be trivial (and is a good
thing to do regardless).
--
Josh
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2025-09-04 17:14 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-09-04 13:18 [RFC] Don't create sframes during build Sebastian Andrzej Siewior
2025-09-04 14:02 ` Matthias Klose
2025-09-04 16:26 ` Matthias Klose
2025-09-04 16:34 ` Sebastian Andrzej Siewior
2025-09-04 17:14 ` Josh Poimboeuf
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).