Live Patching
 help / color / mirror / Atom feed
From: Jens Remus <jremus@linux.ibm.com>
To: Dylan Hatch <dylanbhatch@google.com>,
	Mostafa Saleh <smostafa@google.com>
Cc: 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: Tue, 19 May 2026 13:05:23 +0200	[thread overview]
Message-ID: <4f429a50-df5d-411f-b40e-048d3cad5133@linux.ibm.com> (raw)
In-Reply-To: <CADBMgpx38SUUuYYCm612STqh01jqv817WnJeeXYTD7Uc1r-fug@mail.gmail.com>

Hi Dylan and Mostafa!

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:
>> On Tue, Apr 28, 2026 at 06:36:35PM +0000, Dylan Hatch wrote:
>>> Implement a generic kernel sframe-based [1] unwinder. The main goal is
>>> to improve reliable stacktrace on arm64 by unwinding across exception
>>> boundaries.
>>>
>>> On x86, the ORC unwinder provides reliable stacktrace through similar
>>> methodology, but arm64 lacks the necessary support from objtool to
>>> create ORC unwind tables.
>>>
>>> Currently, there's already a sframe unwinder proposed for userspace: [2].
>>> To maintain common definitions and algorithms for sframe lookup, a
>>> substantial portion of this patch series aims to refactor the sframe
>>> lookup code to support both kernel and userspace sframe sections.
>>>
>>> Currently, only GNU Binutils support sframe. This series relies on the
>>> Sframe V3 format, which is supported in binutils 2.46.
>>>
>>> These patches are based on Steven Rostedt's sframe/core branch [3],
>>> which is and aggregation of existing work done for x86 sframe userspace
>>> unwind, and contains [2]. This branch is, in turn, based on Linux
>>> v7.0-rc3. This full series (applied to the sframe/core branch) is
>>> available on github: [4].
>>>
>>
>> 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`
> 
> 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)
...

> 
>>
>> I applied this series hoping that fix it, but it doesn't, so far I
>> have this hack :
>> diff --git a/arch/arm64/kernel/vdso/vdso.lds.S b/arch/arm64/kernel/vdso/vdso.lds.S
>> index 52314be29191..53bdf757ee44 100644
>> --- a/arch/arm64/kernel/vdso/vdso.lds.S
>> +++ b/arch/arm64/kernel/vdso/vdso.lds.S
>> @@ -77,7 +77,7 @@ SECTIONS
>>         /DISCARD/       : {
>>                 *(.data .data.* .gnu.linkonce.d.* .sdata*)
>>                 *(.bss .sbss .dynbss .dynsbss)
>> -               *(.eh_frame .eh_frame_hdr)
>> +               *(.eh_frame .eh_frame_hdr .sframe)
>>         }
>>  }
>>
>> diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
>> index 60c8c22fd3e4..759903acd6fc 100644
>> --- a/include/asm-generic/vmlinux.lds.h
>> +++ b/include/asm-generic/vmlinux.lds.h
>> @@ -1064,6 +1064,7 @@
>>         /* ld.bfd warns about .gnu.version* even when not emitted */    \
>>         *(.gnu.version*)                                                \
>>         *(__tracepoint_check)                                           \
>> +       *(.sframe)                                                      \
>>
>>  #define DISCARDS                                                       \
>>         /DISCARD/ : {                                                   \
> 
> Since this series only handles kernel stacktrace, I believe it's
> better to omit the .sframe section entirely in the case where only
> ARCH_SUPPORTS_UNWIND_KERNEL_SFRAME is enabled. I think this hack may
> work better for this purpose:
> 
> diff --git a/arch/arm64/kernel/vdso/Makefile b/arch/arm64/kernel/vdso/Makefile
> index c60ef921956f..29f802bfedb1 100644
> --- a/arch/arm64/kernel/vdso/Makefile
> +++ b/arch/arm64/kernel/vdso/Makefile
> @@ -41,7 +41,7 @@ CC_FLAGS_REMOVE_VDSO := $(CC_FLAGS_FTRACE) -Os
> $(CC_FLAGS_SCS) \
>                         $(CC_FLAGS_LTO) $(CC_FLAGS_CFI) $(CC_FLAGS_SFRAME) \
>                         -Wmissing-prototypes -Wmissing-declarations
> 
> -CC_FLAGS_ADD_VDSO := -O2 -mcmodel=tiny -fasynchronous-unwind-tables
> +CC_FLAGS_ADD_VDSO := -O2 -mcmodel=tiny -fasynchronous-unwind-tables
> -Wa,--gsframe=no
> 
>  CFLAGS_REMOVE_vgettimeofday.o = $(CC_FLAGS_REMOVE_VDSO)
>  CFLAGS_REMOVE_vgetrandom.o = $(CC_FLAGS_REMOVE_VDSO)
> 
> Though, I don't understand why it is necessary to provide --gsframe=no
> explicitly. If this approach seems ok to other folks/maintainers, I
> can fold this into my series.

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)?

$ make mrproper
$ make defconfig
$ ./scripts/config --enable HAVE_UNWIND_KERNEL_SFRAME   # enable kernel sframe unwinder
$ make arch/arm64/kernel/vdso/ V=1

> 
> On the topic of SFrame for VDSO, Jens has a patch adding support for
> this as part of a series to support userspace SFrame unwinding for
> arm64:
> 
> https://lore.kernel.org/lkml/20260417150827.1183376-4-jremus@linux.ibm.com/

Any feedback is very welcome. :-)

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/


      reply	other threads:[~2026-05-19 11:06 UTC|newest]

Thread overview: 31+ 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 [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=4f429a50-df5d-411f-b40e-048d3cad5133@linux.ibm.com \
    --to=jremus@linux.ibm.com \
    --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=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