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[ 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.
On 9/4/2025 4:02 PM, 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. ... >> 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: Instead of dropping .sframe for kernel during final link it would be better not to generate it to save some CPU cycles and disk space. >> >> 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. What about: diff --git a/Makefile b/Makefile --- a/Makefile +++ b/Makefile @@ -906,6 +906,11 @@ 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 in assembler by default +CC_FLAGS_SFRAME := $(call as-option,-Wa$(comma)--gsframe=no) +KBUILD_CFLAGS += $(CC_FLAGS_SFRAME) +KBUILD_AFLAGS += $(CC_FLAGS_SFRAME) + ifdef CONFIG_READABLE_ASM # Disable optimizations that make assembler listings hard to read. # reorder blocks reorders the control in the function Generation of .sframe in vDSO can override that default. If archs like arm64 want to enable .sframe for kernel they can introduce a kernel option (e.g. SFRAME) that changes the default. Regards, Jens -- Jens Remus Linux on Z Development (D3303) jremus@de.ibm.com / jremus@linux.ibm.com IBM Deutschland Research & Development GmbH; Vorsitzender des Aufsichtsrats: Wolfgang Wendt; Geschäftsführung: David Faller; Sitz der Gesellschaft: Ehningen; Registergericht: Amtsgericht Stuttgart, HRB 243294 IBM Data Privacy Statement: https://www.ibm.com/privacy/
On Thu, Jan 29, 2026 at 10:13:03AM +0100, Jens Remus wrote:
> Instead of dropping .sframe for kernel during final link it would be
> better not to generate it to save some CPU cycles and disk space.
...
> What about:
>
> diff --git a/Makefile b/Makefile
> --- a/Makefile
> +++ b/Makefile
> @@ -906,6 +906,11 @@ 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 in assembler by default
> +CC_FLAGS_SFRAME := $(call as-option,-Wa$(comma)--gsframe=no)
> +KBUILD_CFLAGS += $(CC_FLAGS_SFRAME)
> +KBUILD_AFLAGS += $(CC_FLAGS_SFRAME)
> +
> ifdef CONFIG_READABLE_ASM
> # Disable optimizations that make assembler listings hard to read.
> # reorder blocks reorders the control in the function
This seems like a good start for the main kernel build. I still have an
issue with bleeding edge binutils with mismatched .sframe input
sections, which does not appear to disappear with -Wa,--gsframe=no.
$ cat test.c
void atexit();
void main() { atexit(); }
$ gcc --version | head -1
gcc (GCC) 15.2.1 20260103
$ ld --version | head -1
GNU ld (GNU Binutils) 2.45.50.20260128
$ gcc -o /dev/null test.c
.../binutils/2.45.50-2026-01-27_18-02-52-e8108cc5e6fe1748dc6033a297dd2c1c6234de78/bin/ld: input SFrame sections with different format versions prevent .sframe generation
.../binutils/2.45.50-2026-01-27_18-02-52-e8108cc5e6fe1748dc6033a297dd2c1c6234de78/bin/ld: final link failed
collect2: error: ld returned 1 exit status
$ gcc -o /dev/null -Wa,--gsframe=no test.c
.../binutils/2.45.50-2026-01-27_18-02-52-e8108cc5e6fe1748dc6033a297dd2c1c6234de78/bin/ld: input SFrame sections with different format versions prevent .sframe generation
.../binutils/2.45.50-2026-01-27_18-02-52-e8108cc5e6fe1748dc6033a297dd2c1c6234de78/bin/ld: final link failed
collect2: error: ld returned 1 exit status
$ gcc -o /dev/null -Wl,--discard-sframe test.c
This was extracted from an error I see while building libiberty in
binutils due to the atexit() configure test failing then the fallback to
on_exit() resulting in an error but I also notice it when building
tools/objtool, which is a host tool:
$ make -skj"$(nproc)" ARCH=x86_64 mrproper defconfig prepare
.../binutils/2.45.50-2026-01-27_18-02-52-e8108cc5e6fe1748dc6033a297dd2c1c6234de78/bin/ld: input SFrame sections with different format versions prevent .sframe generation
.../binutils/2.45.50-2026-01-27_18-02-52-e8108cc5e6fe1748dc6033a297dd2c1c6234de78/bin/ld: final link failed
collect2: error: ld returned 1 exit status
make[5]: *** [Makefile:127: tools/objtool/objtool] Error 1
...
It looks like several distribution ELF objects and libraries on my
system (Arch Linux) have .sframe sections in them, so maybe we still
need -Wl,--discard-sframe? They all appear to be SFrame v2 objects so if
no objects in the build have SFrame v3 sections from -Wa,--gsframe=no,
it seems odd that there is an error but maybe there is something else
going on?
Cheers,
Nathan
On 1/29/26 2:23 PM, Nathan Chancellor wrote:
> On Thu, Jan 29, 2026 at 10:13:03AM +0100, Jens Remus wrote:
>> Instead of dropping .sframe for kernel during final link it would be
>> better not to generate it to save some CPU cycles and disk space.
> ...
>> What about:
>>
>> diff --git a/Makefile b/Makefile
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -906,6 +906,11 @@ 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 in assembler by default
>> +CC_FLAGS_SFRAME := $(call as-option,-Wa$(comma)--gsframe=no)
>> +KBUILD_CFLAGS += $(CC_FLAGS_SFRAME)
>> +KBUILD_AFLAGS += $(CC_FLAGS_SFRAME)
>> +
>> ifdef CONFIG_READABLE_ASM
>> # Disable optimizations that make assembler listings hard to read.
>> # reorder blocks reorders the control in the function
>
> This seems like a good start for the main kernel build. I still have an
> issue with bleeding edge binutils with mismatched .sframe input
> sections, which does not appear to disappear with -Wa,--gsframe=no.
>
> $ cat test.c
> void atexit();
> void main() { atexit(); }
>
> $ gcc --version | head -1
> gcc (GCC) 15.2.1 20260103
>
> $ ld --version | head -1
> GNU ld (GNU Binutils) 2.45.50.20260128
>
> $ gcc -o /dev/null test.c
> .../binutils/2.45.50-2026-01-27_18-02-52-e8108cc5e6fe1748dc6033a297dd2c1c6234de78/bin/ld: input SFrame sections with different format versions prevent .sframe generation
> .../binutils/2.45.50-2026-01-27_18-02-52-e8108cc5e6fe1748dc6033a297dd2c1c6234de78/bin/ld: final link failed
> collect2: error: ld returned 1 exit status
>
> $ gcc -o /dev/null -Wa,--gsframe=no test.c
> .../binutils/2.45.50-2026-01-27_18-02-52-e8108cc5e6fe1748dc6033a297dd2c1c6234de78/bin/ld: input SFrame sections with different format versions prevent .sframe generation
> .../binutils/2.45.50-2026-01-27_18-02-52-e8108cc5e6fe1748dc6033a297dd2c1c6234de78/bin/ld: final link failed
> collect2: error: ld returned 1 exit status
>
> $ gcc -o /dev/null -Wl,--discard-sframe test.c
>
> This was extracted from an error I see while building libiberty in
> binutils due to the atexit() configure test failing then the fallback to
> on_exit() resulting in an error but I also notice it when building
> tools/objtool, which is a host tool:
>
> $ make -skj"$(nproc)" ARCH=x86_64 mrproper defconfig prepare
> .../binutils/2.45.50-2026-01-27_18-02-52-e8108cc5e6fe1748dc6033a297dd2c1c6234de78/bin/ld: input SFrame sections with different format versions prevent .sframe generation
> .../binutils/2.45.50-2026-01-27_18-02-52-e8108cc5e6fe1748dc6033a297dd2c1c6234de78/bin/ld: final link failed
> collect2: error: ld returned 1 exit status
> make[5]: *** [Makefile:127: tools/objtool/objtool] Error 1
> ...
>
> It looks like several distribution ELF objects and libraries on my
> system (Arch Linux) have .sframe sections in them, so maybe we still
> need -Wl,--discard-sframe? They all appear to be SFrame v2 objects so if
> no objects in the build have SFrame v3 sections from -Wa,--gsframe=no,
> it seems odd that there is an error but maybe there is something else
> going on?
>
As to whats going on:
Some Arch Linux releases seem to have glibc configured with
--enable-sframe, which is likely the cause of the SFrame V2 objects on
your system. Frederick (from ArchLinux is in CC) is planning to roll
out a release with a glibc built without --enable-sframe.
Next, GNU ld creates linker-generated .sframe for the (linker-generated)
.plt sections (on x86_64 and s390x), if GNU ld sees any input objects
have .sframe in them[*], unless --discard-sframe is specified. These
are now SFrame V3 (after Jan 15 when SFrame V3 was merged). The choice
to drop the support for V2/V3 object mixing in the GNU ld was made to
save implementation complexity in linkers and (WIP) stacktracers
supporting SFrame, by adopting SFrame V3 and above.
So, --discard-sframe is the remedy if you have V2 sections lying around.
[*] The bug in the GNU Binutils snapshots between Jan 15 and Jan 24 was
that these linker-generated .sframe for .plt were enthusiastically
created even when _none_ of the inputs had .sframe in them (for x86_64
and s390x), unless --discard-sframe was specified.
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
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
On 2025-09-04 10:14 -0700, Josh Poimboeuf wrote:
> 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).
What is the status of sframe support in the kernel? With current
binutils (version 2.45.50.20260119-1) from Debian I could not build
Linux 6.18.7:
,----
| # LD arch/x86/boot/compressed/vmlinux
| ld -m elf_x86_64 --no-ld-generated-unwind-info -pie --no-dynamic-linker --orphan-handling=error -z noexecstack --no-warn-rwx-segments -T arch/x86/boot/compressed/vmlinux.lds arch/x86/boot/compressed/kernel_info.o arch/x86/boot/compressed/head_64.o arch/x86/boot/compressed/misc.o arch/x86/boot/compressed/string.o arch/x86/boot/compressed/cmdline.o arch/x86/boot/compressed/error.o arch/x86/boot/compressed/piggy.o arch/x86/boot/compressed/cpuflags.o arch/x86/boot/compressed/early_serial_console.o arch/x86/boot/compressed/kaslr.o arch/x86/boot/compressed/ident_map_64.o arch/x86/boot/compressed/idt_64.o arch/x86/boot/compressed/idt_handlers_64.o arch/x86/boot/compressed/pgtable_64.o arch/x86/boot/compressed/acpi.o arch/x86/boot/startup/lib.a -o arch/x86/boot/compressed/vmlinux
| /usr/bin/x86_64-linux-gnu-ld.bfd: error: unplaced orphan section `.sframe' from `arch/x86/boot/compressed/kernel_info.o'
| /usr/bin/x86_64-linux-gnu-ld.bfd: error: unplaced orphan section `.sframe' from `arch/x86/boot/compressed/kernel_info.o'
| make[6]: *** [arch/x86/boot/compressed/Makefile:116: arch/x86/boot/compressed/vmlinux] Error 1
| make[5]: *** [arch/x86/boot/Makefile:96: arch/x86/boot/compressed/vmlinux] Error 2
`----
Did not test mainline yet, but "git log --grep=sframe master" does not
show anything interesting.
Cheers,
Sven
On 2026-01-24 4:04 a.m., Sven Joachim wrote: > On 2025-09-04 10:14 -0700, Josh Poimboeuf wrote: > >> 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). > > What is the status of sframe support in the kernel? With current > binutils (version 2.45.50.20260119-1) from Debian I could not build > Linux 6.18.7: > > ,---- > | # LD arch/x86/boot/compressed/vmlinux > | ld -m elf_x86_64 --no-ld-generated-unwind-info -pie --no-dynamic-linker --orphan-handling=error -z noexecstack --no-warn-rwx-segments -T arch/x86/boot/compressed/vmlinux.lds arch/x86/boot/compressed/kernel_info.o arch/x86/boot/compressed/head_64.o arch/x86/boot/compressed/misc.o arch/x86/boot/compressed/string.o arch/x86/boot/compressed/cmdline.o arch/x86/boot/compressed/error.o arch/x86/boot/compressed/piggy.o arch/x86/boot/compressed/cpuflags.o arch/x86/boot/compressed/early_serial_console.o arch/x86/boot/compressed/kaslr.o arch/x86/boot/compressed/ident_map_64.o arch/x86/boot/compressed/idt_64.o arch/x86/boot/compressed/idt_handlers_64.o arch/x86/boot/compressed/pgtable_64.o arch/x86/boot/compressed/acpi.o arch/x86/boot/startup/lib.a -o arch/x86/boot/compressed/vmlinux > | /usr/bin/x86_64-linux-gnu-ld.bfd: error: unplaced orphan section `.sframe' from `arch/x86/boot/compressed/kernel_info.o' > | /usr/bin/x86_64-linux-gnu-ld.bfd: error: unplaced orphan section `.sframe' from `arch/x86/boot/compressed/kernel_info.o' > | make[6]: *** [arch/x86/boot/compressed/Makefile:116: arch/x86/boot/compressed/vmlinux] Error 1 > | make[5]: *** [arch/x86/boot/Makefile:96: arch/x86/boot/compressed/vmlinux] Error 2 > `---- > Sorry for the breakage. There is a patch that needs to make it upstream https://sourceware.org/pipermail/binutils/2026-January/147664.html (Its a part of a series under review..) I will work on getting this patch committed. For immediate relief, please use the new ld option --discard-sframe meanwhile. > Did not test mainline yet, but "git log --grep=sframe master" does not > show anything interesting. > > Cheers, > Sven
On 1/24/26 11:08 AM, Indu wrote: > On 2026-01-24 4:04 a.m., Sven Joachim wrote: >> On 2025-09-04 10:14 -0700, Josh Poimboeuf wrote: >> >>> 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). >> >> What is the status of sframe support in the kernel? With current >> binutils (version 2.45.50.20260119-1) from Debian I could not build >> Linux 6.18.7: >> >> ,---- >> | # LD arch/x86/boot/compressed/vmlinux >> | ld -m elf_x86_64 --no-ld-generated-unwind-info -pie --no- >> dynamic-linker --orphan-handling=error -z noexecstack --no-warn-rwx- >> segments -T arch/x86/boot/compressed/vmlinux.lds arch/x86/boot/ >> compressed/kernel_info.o arch/x86/boot/compressed/head_64.o arch/x86/ >> boot/compressed/misc.o arch/x86/boot/compressed/string.o arch/x86/ >> boot/compressed/cmdline.o arch/x86/boot/compressed/error.o arch/x86/ >> boot/compressed/piggy.o arch/x86/boot/compressed/cpuflags.o arch/x86/ >> boot/compressed/early_serial_console.o arch/x86/boot/compressed/ >> kaslr.o arch/x86/boot/compressed/ident_map_64.o arch/x86/boot/ >> compressed/idt_64.o arch/x86/boot/compressed/idt_handlers_64.o arch/ >> x86/boot/compressed/pgtable_64.o arch/x86/boot/compressed/acpi.o arch/ >> x86/boot/startup/lib.a -o arch/x86/boot/compressed/vmlinux >> | /usr/bin/x86_64-linux-gnu-ld.bfd: error: unplaced orphan section >> `.sframe' from `arch/x86/boot/compressed/kernel_info.o' >> | /usr/bin/x86_64-linux-gnu-ld.bfd: error: unplaced orphan section >> `.sframe' from `arch/x86/boot/compressed/kernel_info.o' >> | make[6]: *** [arch/x86/boot/compressed/Makefile:116: arch/x86/boot/ >> compressed/vmlinux] Error 1 >> | make[5]: *** [arch/x86/boot/Makefile:96: arch/x86/boot/compressed/ >> vmlinux] Error 2 >> `---- >> > > Sorry for the breakage. > > There is a patch that needs to make it upstream > https://sourceware.org/pipermail/binutils/2026-January/147664.html > (Its a part of a series under review..) > > I will work on getting this patch committed. > > For immediate relief, please use the new ld option --discard-sframe > meanwhile. > This was being tracked via https://www.sourceware.org/bugzilla/show_bug.cgi?id=33830. Should be fixed now on Binutils master and 2.46 branch. Thanks >> Did not test mainline yet, but "git log --grep=sframe master" does not >> show anything interesting. >> >> Cheers, >> Sven > >
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.
© 2016 - 2026 Red Hat, Inc.