Re: [PATCH v8 01/11] arm64, unwind: build kernel with sframe V3 info

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] unwind: missing SFrame unwind information for Rust code
--

commit 531ea7668c66f4aab865a6399bb07911c3617223
Author: Dylan Hatch <dylanbhatch@xxxxxxxxxx>

arm64, unwind: build kernel with sframe V3 info

To generate a .sframe section, build with -Wa,--gsframe-3 flags. Also,
add unwind-table options to ensure the necessary CFI directives are
emitted by the compiler, but discard .eh_frame unless
CONFIG_UNWIND_TABLES is explicitly enabled.

> diff --git a/Makefile b/Makefile
> index 7c855e6fe5448..5c2ca98a86786 100644
> --- a/Makefile
> +++ b/Makefile
[ ... ]
> @@ -1197,6 +1197,14 @@ CFLAGS_GCOV	+= $(call try-run,\
>  endif
>  export CFLAGS_GCOV
>  
> +# 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)

[Severity: Medium]
When CONFIG_HAVE_UNWIND_KERNEL_SFRAME is enabled, the generation flag is
added to C and ASM flags in Makefile, but no equivalent flag is passed to
the Rust compiler.

Because rustc emits object files directly using its LLVM backend and
currently lacks native SFrame emission, does it generate standard .eh_frame
data instead of .sframe?

> +export CC_FLAGS_SFRAME
> +endif
> +
>  # change __FILE__ to the relative path to the source directory
>  ifdef building_out_of_srctree
[ ... ]
> diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
> index 6b005c8fef706..ae1c23579ad2f 100644
> --- a/arch/arm64/Makefile
> +++ b/arch/arm64/Makefile
[ ... ]
> @@ -55,7 +55,7 @@ KBUILD_CFLAGS	+= $(call cc-option,-mabi=lp64)
>  KBUILD_AFLAGS	+= $(call cc-option,-mabi=lp64)
>  
>  # Avoid generating .eh_frame* sections.
> -ifneq ($(CONFIG_UNWIND_TABLES),y)
> +ifeq ($(filter y, $(CONFIG_UNWIND_TABLES) $(CONFIG_HAVE_UNWIND_KERNEL_SFRAME)),)
>  KBUILD_CFLAGS	+= -fno-asynchronous-unwind-tables -fno-unwind-tables
>  KBUILD_AFLAGS	+= -fno-asynchronous-unwind-tables -fno-unwind-tables
>  KBUILD_RUSTFLAGS += -Cforce-unwind-tables=n

[Severity: Medium]
In arch/arm64/Makefile, this change ensures that Rust continues generating
unwind tables when SFrame is enabled. Does this mean Rust will continue to
generate DWARF unwind tables since -Cforce-unwind-tables=n is not applied
when CONFIG_HAVE_UNWIND_KERNEL_SFRAME is enabled and CONFIG_UNWIND_TABLES
is disabled?

[ ... ]
> diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
> index af1d720209764..eb1f54829503c 100644
> --- a/arch/arm64/kernel/vmlinux.lds.S
> +++ b/arch/arm64/kernel/vmlinux.lds.S
[ ... ]
> @@ -145,14 +145,25 @@ jiffies = jiffies_64;
>  #endif
>  
>  #ifdef CONFIG_UNWIND_TABLES
> +
>  #define UNWIND_DATA_SECTIONS				\
>  	.eh_frame : {					\
>  		__pi___eh_frame_start = .;		\
>  		*(.eh_frame)				\
>  		__pi___eh_frame_end = .;		\
>  	}
> +#define SFRAME_DISCARDS
> +
> +#elif defined(CONFIG_HAVE_UNWIND_KERNEL_SFRAME)
> +
> +#define UNWIND_DATA_SECTIONS
> +#define SFRAME_DISCARDS *(.eh_frame)

[Severity: Medium]
When only CONFIG_HAVE_UNWIND_KERNEL_SFRAME is enabled and
CONFIG_UNWIND_TABLES is disabled, the .eh_frame sections are explicitly
discarded here in arch/arm64/kernel/vmlinux.lds.S.

Since Rust code emits .eh_frame data instead of .sframe, does discarding
these sections silently leave all compiled Rust objects without any unwind
information? Could this break reliable stack unwinding across Rust frames?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261007114335.440322-1-dylanbhatch@xxxxxxxxxx?part=1