From: Brian Norris <briannorris@chromium.org>
To: Jens Remus <jremus@linux.ibm.com>
Cc: Dylan Hatch <dylanbhatch@google.com>,
Mostafa Saleh <smostafa@google.com>,
Roman Gushchin <roman.gushchin@linux.dev>,
Weinan Liu <wnliu@google.com>, Will Deacon <will@kernel.org>,
Josh Poimboeuf <jpoimboe@kernel.org>,
Indu Bhagat <ibhagatgnu@gmail.com>,
Peter Zijlstra <peterz@infradead.org>,
Steven Rostedt <rostedt@goodmis.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Jiri Kosina <jikos@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Prasanna Kumar T S M <ptsm@linux.microsoft.com>,
Puranjay Mohan <puranjay@kernel.org>, Song Liu <song@kernel.org>,
joe.lawrence@redhat.com, linux-toolchains@vger.kernel.org,
linux-kernel@vger.kernel.org, live-patching@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
Randy Dunlap <rdunlap@infradead.org>
Subject: Re: [PATCH v5 0/8] unwind, arm64: add sframe unwinder for kernel
Date: Mon, 13 Jul 2026 17:28:40 -0700 [thread overview]
Message-ID: <alWCuAA7r1otvROg@google.com> (raw)
In-Reply-To: <4f429a50-df5d-411f-b40e-048d3cad5133@linux.ibm.com>
Hi Jens,
On Tue, May 19, 2026 at 01:05:23PM +0200, Jens Remus wrote:
> Hi Dylan and Mostafa!
I also work at the same company as Dylan and Mostafa, and am therefore
probably using the same company-maintained Linux distribution.
> On 5/18/2026 7:55 PM, Dylan Hatch wrote:
> > On Fri, May 15, 2026 at 4:32 AM Mostafa Saleh <smostafa@google.com> wrote:
> >> Not sure if related, but after updating my toolchain
> >> (aarch64-linux-gnu-gcc (Debian 15.2.0-4) 15.2.0), I hit link errors:
> >> ld.lld: error: arch/arm64/kernel/vdso/vgettimeofday.o:(.sframe) is being placed in '.sframe'
> >> ld.lld: error: arch/arm64/kernel/vdso/vgetrandom.o:(.sframe) is being placed in '.sframe`
I've also been hitting this for some time, and I'd like to see if I can
figure out what's going wrong. My current workaround is:
--- a/Makefile
+++ b/Makefile
@@ -946,6 +946,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.
> > Previously when developing against the SFrame V2 format, I had fixed
> > these warnings with the VDSO Makefile change currently in this series:
> >
> > diff --git a/arch/arm64/kernel/vdso/Makefile b/arch/arm64/kernel/vdso/Makefile
> > index 7dec05dd33b7..c60ef921956f 100644
> > --- a/arch/arm64/kernel/vdso/Makefile
> > +++ b/arch/arm64/kernel/vdso/Makefile
> > @@ -38,7 +38,7 @@ ccflags-y += -DDISABLE_BRANCH_PROFILING -DBUILD_VDSO
> > CC_FLAGS_REMOVE_VDSO := $(CC_FLAGS_FTRACE) -Os $(CC_FLAGS_SCS) \
> > $(RANDSTRUCT_CFLAGS) $(KSTACK_ERASE_CFLAGS) \
> > $(GCC_PLUGINS_CFLAGS) \
> > - $(CC_FLAGS_LTO) $(CC_FLAGS_CFI) \
> > + $(CC_FLAGS_LTO) $(CC_FLAGS_CFI) $(CC_FLAGS_SFRAME) \
> > -Wmissing-prototypes -Wmissing-declarations
> >
> > CC_FLAGS_ADD_VDSO := -O2 -mcmodel=tiny -fasynchronous-unwind-tables
> >
> > But the warnings seem to have returned after upgrading my toolchain,
> > possibly due to SFrame V3 or some confounding change in GCC. The
> > --gsframe in the assembler should be set to 'no' by default, so
> > perhaps GCC is providing an override --gsframe internally?
>
> Could it be that your build of binutils was configured with
> --enable-default-sframe, so that the GNU assembler defaults to generate
> .sframe? AFAIK this configure option was meant for distributors and
> package maintainers.
>
> You can check as follows whether --gsframe defaults to "no" or "yes":
>
> $ as --help | grep -A1 gsframe
> --gsframe[={no|yes}] whether to generate SFrame stack trace information
> (default: no)
> ...
$ aarch64-linux-gnu-as --help | grep -A1 gsframe
--gsframe[={no|yes}] whether to generate SFrame stack trace information
(default: no)
--
--gsframe-<N> generate SFrame version <N> information. 3 == <N>
--scfi=experimental Synthesize DWARF CFI for hand-written asm
> Maybe build the VDSO separately with V=1 to see what assembler/compiler
> options are effectively used (e.g. for vgettimeofday.o and vgetrandom.o
> mentioned in the linker error message above)?
A slightly tweaked version of my vgetrandom.o build line:
# CC arch/arm64/kernel/vdso/vgetrandom.o
aarch64-linux-gnu-gcc -Wp,-MMD,arch/arm64/kernel/vdso/.vgetrandom.o.d -nostdinc -I./arch/arm64/include -I./arch/arm64/include/generated -I./include -I./include -I./arch/arm64/include/uapi -I./arch/arm64/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/compiler-version.h -include ./include/linux/kconfig.h -include ./include/linux/compiler_types.h -D__KERNEL__ -mlittle-endian -DCC_USING_PATCHABLE_FUNCTION_ENTRY -DKASAN_SHADOW_SCALE_SHIFT= -Werror -fshort-wchar -funsigned-char -fno-common -fno-PIE -fno-strict-aliasing -std=gnu11 -fms-extensions -mgeneral-regs-only -DCONFIG_CC_HAS_K_CONSTRAINT=1 -Wno-psabi -mabi=lp64 -fno-asynchronous-unwind-tables -fno-unwind-tables -mbranch-protection=pac-ret -Wa,-march=armv8.5-a -DARM64_ASM_ARCH='"armv8.5-a"' -DKASAN_SHADOW_SCALE_SHIFT= -fno-delete-null-pointer-checks -O2 -fno-allow-store-data-races -fstack-protector-strong -fno-omit-frame-pointer -fno-optimize-sibling-calls -ftrivial-auto-var-init=zero -fzero-init-padding-bits=all -fno-stack-clash-protection -fno-inline-functions-called-once -fmin-function-alignment=8 -fstrict-flex-arrays=3 -fno-strict-overflow -fno-stack-check -fconserve-stack -fno-builtin-wcslen -Wall -Wextra -Wundef -Werror=implicit-function-declaration -Werror=implicit-int -Werror=return-type -Werror=strict-prototypes -Wno-format-security -Wno-trigraphs -Wno-frame-address -Wno-address-of-packed-member -Wframe-larger-than=2048 -Wno-main -Wno-type-limits -Wno-dangling-pointer -Wvla-larger-than=1 -Wno-pointer-sign -Wcast-function-type -Wno-unterminated-string-initialization -Wno-array-bounds -Wno-stringop-overflow -Wno-alloc-size-larger-than -Wimplicit-fallthrough=5 -Werror=date-time -Werror=incompatible-pointer-types -Werror=designated-init -Wenum-conversion -Wunused -Wno-unused-but-set-variable -Wno-unused-const-variable -Wno-packed-not-aligned -Wno-format-overflow -Wno-format-truncation -Wno-stringop-truncation -Wno-override-init -Wno-missing-field-initializers -Wno-shift-negative-value -Wno-maybe-uninitialized -Wno-sign-compare -Wno-unused-parameter -g -mstack-protector-guard=sysreg -mstack-protector-guard-reg=sp_el0 -mstack-protector-guard-offset=1344 -fno-common -fno-builtin -fno-stack-protector -ffixed-x18 -DDISABLE_BRANCH_PROFILING -DBUILD_VDSO -O2 -mcmodel=tiny -fasynchronous-unwind-tables -include ./lib/vdso/getrandom.c -I./arch/arm64/kernel/vdso -Iarch/arm64/kernel/vdso -DKBUILD_MODFILE='"arch/arm64/kernel/vdso/vgetrandom"' -DKBUILD_BASENAME='"vgetrandom"' -DKBUILD_MODNAME='"vgetrandom"' -D__KBUILD_MODNAME=vgetrandom -c -o arch/arm64/kernel/vdso/vgetrandom.o ./arch/arm64/kernel/vdso/vgetrandom.c
I mostly don't know what I'm looking for w.r.t. gsframe features, but
I'm willing to poke at my compiler/assembler/build-process.
Brian
prev parent reply other threads:[~2026-07-14 0:28 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-28 18:36 [PATCH v5 0/8] unwind, arm64: add sframe unwinder for kernel Dylan Hatch
2026-04-28 18:36 ` [PATCH v5 1/8] sframe: Allow kernelspace sframe sections Dylan Hatch
2026-04-28 18:36 ` [PATCH v5 2/8] arm64, unwind: build kernel with sframe V3 info Dylan Hatch
2026-04-28 18:36 ` [PATCH v5 3/8] arm64: entry: add unwind info for various kernel entries Dylan Hatch
2026-04-29 15:26 ` Mark Rutland
2026-05-15 3:30 ` Dylan Hatch
2026-05-15 8:58 ` Mark Rutland
2026-05-18 22:41 ` Dylan Hatch
2026-04-28 18:36 ` [PATCH v5 4/8] sframe: Provide PC lookup for vmlinux .sframe section Dylan Hatch
2026-04-28 18:36 ` [PATCH v5 5/8] sframe: Allow unsorted FDEs Dylan Hatch
2026-04-30 10:04 ` Jens Remus
2026-04-28 18:36 ` [PATCH v5 6/8] arm64/module, sframe: Add sframe support for modules Dylan Hatch
2026-04-30 10:04 ` Jens Remus
2026-04-28 18:36 ` [PATCH v5 7/8] sframe: Introduce in-kernel SFRAME_VALIDATION Dylan Hatch
2026-04-30 10:04 ` Jens Remus
2026-04-28 18:36 ` [PATCH v5 8/8] unwind: arm64: Use sframe to unwind interrupt frames Dylan Hatch
2026-05-01 16:46 ` Mark Rutland
2026-05-04 8:47 ` Jens Remus
2026-05-05 10:29 ` Mark Rutland
2026-05-05 15:52 ` Jens Remus
2026-05-12 3:00 ` Dylan Hatch
2026-05-12 8:55 ` Jens Remus
2026-05-12 10:18 ` Mark Rutland
2026-05-12 10:07 ` Mark Rutland
2026-05-19 6:29 ` Dylan Hatch
2026-04-29 17:18 ` [PATCH v5 0/8] unwind, arm64: add sframe unwinder for kernel Mark Rutland
2026-04-30 10:11 ` Jens Remus
2026-05-12 1:10 ` Dylan Hatch
2026-05-15 11:32 ` Mostafa Saleh
2026-05-18 17:55 ` Dylan Hatch
2026-05-19 11:05 ` Jens Remus
2026-07-14 0:28 ` Brian Norris [this message]
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=alWCuAA7r1otvROg@google.com \
--to=briannorris@chromium.org \
--cc=catalin.marinas@arm.com \
--cc=dylanbhatch@google.com \
--cc=ibhagatgnu@gmail.com \
--cc=jikos@kernel.org \
--cc=joe.lawrence@redhat.com \
--cc=jpoimboe@kernel.org \
--cc=jremus@linux.ibm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-toolchains@vger.kernel.org \
--cc=live-patching@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=peterz@infradead.org \
--cc=ptsm@linux.microsoft.com \
--cc=puranjay@kernel.org \
--cc=rdunlap@infradead.org \
--cc=roman.gushchin@linux.dev \
--cc=rostedt@goodmis.org \
--cc=smostafa@google.com \
--cc=song@kernel.org \
--cc=will@kernel.org \
--cc=wnliu@google.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox