Re: [PATCH v2 0/8] dce, riscv: Unused syscall trimming with PUSHSECTION and conditional KEEP()

["Arnd Bergmann" <arnd@arndb.de>]

On Wed, Oct 15, 2025, at 08:16, Yuan Tan wrote:
> Hi all,
>
> This series aims to introduce syscall trimming support based on dead code
> and data elimination (DCE). This can reduce the final image size, which is
> particularly useful for embedded devices, while also reducing the attack
> surface. It might further benefit specialized scenarios such as unikernels
> or LTO builds, and could potentially help shrink the instruction cache
> footprint.
>
> Besides that, this series also introduces a new PUSHSECTION macro. This
> wrapper allows sections created by .pushsection to have a proper reference
> relationship with their callers, so that --gc-sections can safely work
> without requiring unconditional KEEP() entries in linker scripts.
>
> Since the new syscalltbl.sh infrastructure has been merged, I think it’s a
> good time to push this patchsetTODO? forward.
>
> Patch 1–3 introduce the infrastructure for TRIM_UNUSED_SYSCALLS, mainly
> allowing syscalltbl.sh to decide which syscalls to keep according to
> USED_SYSCALLS.
> Patch 4 enables TRIM_UNUSED_SYSCALLS for the RISC-V architecture. With
> syscalltbl.sh now available, this feature should be applicable to all
> architectures that support LD_DEAD_CODE_DATA_ELIMINATION and use
> syscalltbl.sh, but let’s focus on RISC-V first.
> Patch 5–8 address the dependency inversion problem caused by sections
> created with .pushsection that are forcibly retained by KEEP() in linker
> scripts.

Thanks a lot for your work on this. I think it is indeed valuable to
be able to optimize kernels with a smaller subset of system calls for
known workloads, and have as much dead code elimination as possible.

However, I continue to think that the added scripting with a known
set of syscall names is fundamentally the wrong approach to get to
this list: This adds complexity to the build process in one of
the areas that is already too complicated, and it duplicates what
we can already do with Kconfig for a subset of the system calls.

I think the way we should configure the set of syscalls instead is
to add more Kconfig symbols guarded by CONFIG_EXPERT that turn
classes of syscalls on or off. You have obviously done the research
to come up with a list of used/unused entry points for one or more
workloads. Can you share those lists?

      Arnd