From: Nathan Chancellor <nathan@kernel.org>
To: Jens Remus <jremus@linux.ibm.com>
Cc: Matthias Klose <doko@debian.org>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-kbuild@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>,
Josh Poimboeuf <jpoimboe@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Nicolas Schier <nicolas.schier@linux.dev>,
Binutils <binutils@sourceware.org>,
Heiko Carstens <hca@linux.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Indu Bhagat <indu.bhagat@oracle.com>
Subject: Re: [RFC] Don't create sframes during build
Date: Thu, 29 Jan 2026 15:23:57 -0700 [thread overview]
Message-ID: <20260129222357.GA493990@ax162> (raw)
In-Reply-To: <7b45d196-063e-4e76-b08b-ec2bcc111328@linux.ibm.com>
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
next prev parent reply other threads:[~2026-01-29 22:24 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
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
2026-01-24 12:04 ` Sven Joachim
2026-01-24 19:08 ` Indu
2026-01-27 18:22 ` Indu Bhagat
2026-01-29 9:13 ` Jens Remus
2026-01-29 22:23 ` Nathan Chancellor [this message]
2026-01-30 0:58 ` Indu Bhagat
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260129222357.GA493990@ax162 \
--to=nathan@kernel.org \
--cc=arnd@arndb.de \
--cc=bigeasy@linutronix.de \
--cc=binutils@sourceware.org \
--cc=doko@debian.org \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=indu.bhagat@oracle.com \
--cc=jpoimboe@kernel.org \
--cc=jremus@linux.ibm.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nicolas.schier@linux.dev \
--cc=peterz@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.