[PATCH v1 3/4] arm64/vdso: Enable SFrame generation in vDSO

[Dylan Hatch]

Hi Jens,

Sorry for the slow reply on this.

On Fri, Apr 17, 2026 at 8:08 AM Jens Remus <jremus at 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 at 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?

Thanks,
Dylan