[PATCH v1 3/4] arm64/vdso: Enable SFrame generation in vDSO
Dylan Hatch
dylanbhatch at google.com
Fri May 22 11:24:42 PDT 2026
On Fri, May 22, 2026 at 1:51 AM Jens Remus <jremus at linux.ibm.com> wrote:
>
> 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 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?
>
> I like that approach. Go ahead.
Do you have an updated version you can send? I noticed some of these
patches don't apply cleanly on Steven's current sframe branch. If you
can't get to it before you leave then no worries, have a good vacation
:)
More information about the linux-arm-kernel
mailing list