From: Jens Remus <jremus@linux•ibm.com>
To: Dylan Hatch <dylanbhatch@google•com>
Cc: Catalin Marinas <catalin.marinas@arm•com>,
Will Deacon <will@kernel•org>,
Steven Rostedt <rostedt@kernel•org>,
Josh Poimboeuf <jpoimboe@kernel•org>,
Indu Bhagat <ibhagatgnu@gmail•com>,
Peter Zijlstra <peterz@infradead•org>,
Weinan Liu <wnliu@google•com>,
linux-arm-kernel@lists•infradead.org,
linux-kernel@vger•kernel.org, Heiko Carstens <hca@linux•ibm.com>,
Ilya Leoshkevich <iii@linux•ibm.com>
Subject: Re: [PATCH v1 3/4] arm64/vdso: Enable SFrame generation in vDSO
Date: Fri, 22 May 2026 10:51:32 +0200 [thread overview]
Message-ID: <48871045-9ec8-4e62-a2c5-809e3070d671@linux.ibm.com> (raw)
In-Reply-To: <CADBMgpwCuYCYPSOCvcm0-rXS=cvFZ-GsP5V1GJFEhghF5JMUDg@mail.gmail.com>
Hello Dylan,
thank you for the feedback!
On 5/22/2026 3:31 AM, Dylan Hatch wrote:
> On Fri, Apr 17, 2026 at 8:08 AM Jens Remus <jremus@linux•ibm.com> wrote:
>>
>> This replicates Josh's x86 patch "x86/vdso: Enable sframe generation
>> in VDSO" [1] for arm64.
>>
>> Enable .sframe generation in the vDSO library so kernel and user space
>> can unwind through it. Keep all function symbols in the vDSO .symtab
>> for stack trace purposes. This enables perf to lookup these function
>> symbols in addition to those already exported in vDSO .dynsym.
>>
>> Starting with binutils 2.46 both GNU assembler and GNU linker
>> exclusively support generating and merging .sframe in SFrame V3 format.
>> For vDSO, only if supported by the assembler, generate .sframe, collect
>> it, mark it as KEEP, and generate a GNU_SFRAME program table entry.
>> Otherwise explicitly discard any .sframe.
>>
>> [1]: x86/vdso: Enable sframe generation in VDSO,
>> https://lore.kernel.org/all/20260211141357.271402-7-jremus@linux.ibm.com/
>>
>> Signed-off-by: Jens Remus <jremus@linux•ibm.com>
>> ---
>>
>> Notes (jremus):
>> @Dylan: Adding -Wa,--gsframe-3 to the VDSO CC_FLAGS_ADD_VDSO (and
>> AS_FLAGS_ADD_VDSO) may clash with your patch [1] that adds likewise
>> to the CC_FLAGS_REMOVE_VDSO. Any idea how to resolve?
>>
>> [1]: [PATCH v3 2/8] arm64, unwind: build kernel with sframe V3 info,
>> https://lore.kernel.org/all/20260406185000.1378082-3-dylanbhatch@google.com/
>
> In a kernel tree with both your patch and my [1] patch merged, I
> believe we'd want to hold two invariants true:
>
> 1. If HAVE_UNWIND_KERNEL_SFRAME=n, we must not build the kernel with .sframe.
> 2. If AS_SFRAME3=y, we must build vDSO with .sframe.
>
> Since HAVE_UNWIND_KERNEL_SFRAME=y implies AS_SFRAME3=y, I wonder if we
> should be able to drop CC_FLAGS_SFRAME from CC_FLAGS_REMOVE_VDSO and
> move some definitions:
>
> diff --git a/Makefile b/Makefile
> index 227fda16deb1..ef059bccb8c1 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1147,12 +1147,15 @@ endif
> # Ensure compilers do not transform certain loops into calls to wcslen()
> KBUILD_CFLAGS += -fno-builtin-wcslen
>
> +ifeq ($(CONFIG_AS_SFRAME3),y)
> +CC_FLAGS_SFRAME := -Wa,--gsframe-3
> +export CC_FLAGS_SFRAME
> +endif
> +
> # build with sframe table
> ifdef CONFIG_HAVE_UNWIND_KERNEL_SFRAME
> -CC_FLAGS_SFRAME := -Wa,--gsframe-3
> KBUILD_CFLAGS += $(CC_FLAGS_SFRAME)
> KBUILD_AFLAGS += $(CC_FLAGS_SFRAME)
> -export CC_FLAGS_SFRAME
> endif
>
> # change __FILE__ to the relative path to the source directory
> diff --git a/arch/arm64/kernel/vdso/Makefile b/arch/arm64/kernel/vdso/Makefile
> index e90427a8d0f6..f03cac27857c 100644
> --- a/arch/arm64/kernel/vdso/Makefile
> +++ b/arch/arm64/kernel/vdso/Makefile
> @@ -15,10 +15,6 @@ obj-vdso := vgettimeofday.o note.o sigreturn.o
> vgetrandom.o vgetrandom-chacha.o
> targets := $(obj-vdso) vdso.so vdso.so.dbg
> obj-vdso := $(addprefix $(obj)/, $(obj-vdso))
>
> -ifeq ($(CONFIG_AS_SFRAME3),y)
> - SFRAME_CFLAGS := -Wa,--gsframe-3
> -endif
> -
> btildflags-$(CONFIG_ARM64_BTI_KERNEL) += -z force-bti
>
> # -Bsymbolic has been added for consistency with arm, the compat vDSO and
> @@ -42,12 +38,12 @@ 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_SFRAME) \
> + $(CC_FLAGS_LTO) $(CC_FLAGS_CFI) \
> -Wmissing-prototypes -Wmissing-declarations
>
> -CC_FLAGS_ADD_VDSO := -O2 -mcmodel=tiny -fasynchronous-unwind-tables
> $(SFRAME_CFLAGS)
> +CC_FLAGS_ADD_VDSO := -O2 -mcmodel=tiny -fasynchronous-unwind-tables
> $(CC_FLAGS_SFRAME)
>
> -AS_FLAGS_ADD_VDSO := $(SFRAME_CFLAGS)
> +AS_FLAGS_ADD_VDSO := $(CC_FLAGS_SFRAME)
>
> CFLAGS_REMOVE_vgettimeofday.o = $(CC_FLAGS_REMOVE_VDSO)
> CFLAGS_REMOVE_vgetrandom.o = $(CC_FLAGS_REMOVE_VDSO)
>
>
> If done this way I think we will add the -Wa,--gsframe-3 twice when
> HAVE_UNWIND_KERNEL_SFRAME=y, but maybe that's not a problem? This
> could probably be folded into either this patch or mine [1], depending
> which is applied first. I'm happy to rebase my unwind-for-kernel
> patches onto this series, or we can do the other way around if that
> works better.
>
> What do you think?
I like that approach. Go ahead.
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/
next prev parent reply other threads:[~2026-05-22 8:52 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-17 15:08 [PATCH v1 0/4] arm64: SFrame user space unwinding Jens Remus
2026-04-17 15:08 ` [PATCH v1 1/4] arm64/unwind_user/fp: Enable HAVE_UNWIND_USER_FP Jens Remus
2026-04-17 15:08 ` [PATCH v1 2/4] arm64/uaccess: Add unsafe_copy_from_user() implementation Jens Remus
2026-04-17 15:08 ` [PATCH v1 3/4] arm64/vdso: Enable SFrame generation in vDSO Jens Remus
2026-05-22 1:31 ` Dylan Hatch
2026-05-22 8:51 ` Jens Remus [this message]
2026-05-22 18:24 ` Dylan Hatch
2026-04-17 15:08 ` [PATCH v1 4/4] arm64/unwind_user/sframe: Enable sframe unwinding on arm64 Jens Remus
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=48871045-9ec8-4e62-a2c5-809e3070d671@linux.ibm.com \
--to=jremus@linux$(echo .)ibm.com \
--cc=catalin.marinas@arm$(echo .)com \
--cc=dylanbhatch@google$(echo .)com \
--cc=hca@linux$(echo .)ibm.com \
--cc=ibhagatgnu@gmail$(echo .)com \
--cc=iii@linux$(echo .)ibm.com \
--cc=jpoimboe@kernel$(echo .)org \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=peterz@infradead$(echo .)org \
--cc=rostedt@kernel$(echo .)org \
--cc=will@kernel$(echo .)org \
--cc=wnliu@google$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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