Re: [PATCH v5 05/24] powerpc/elf: Move relocation constants to UAPI

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Removing PowerPC ELF relocation constants from `uapi/asm/elf.h` without providing a fallback include breaks backward compatibility for userspace compilation.
--

commit 329aaa1bbce8cdbdd0158227a5a1193c91112b27
Author: Thomas Weißschuh <thomas.weissschuh@linutronix.de>

powerpc/elf: Move relocation constants to UAPI

This commit moves the PowerPC ELF relocation constants from the architecture
specific header to the common include/uapi/linux/elf-r.h header. This aims to
make them available for cross-platform userspace tools processing ELF files.

> diff --git a/arch/powerpc/include/uapi/asm/elf.h b/arch/powerpc/include/uapi/asm/elf.h
> index a5377f494fa31..aba921b8249a2 100644
> --- a/arch/powerpc/include/uapi/asm/elf.h
> +++ b/arch/powerpc/include/uapi/asm/elf.h
> @@ -17,78 +17,6 @@
>  #include <asm/cputable.h>
>  #include <asm/auxvec.h>
>  
> -/* PowerPC relocations defined by the ABIs */
> -#define R_PPC_NONE		0
> -#define R_PPC_ADDR32		1	/* 32bit absolute address */

[Severity: Medium]
Does removing these constants without leaving a compatibility include break
backward compatibility for userspace builds?

When a userspace program includes <asm/elf.h> and references R_PPC_* macros
against the updated kernel headers, compilation will fail. Should we add an
#include <linux/elf-r.h> fallback here to maintain the exported API?

The commit message also notes moving these from a "kernel-private" header, 
but since arch/powerpc/include/uapi/asm/elf.h is already within the uapi 
directory, it is already an exported userspace header.

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260908-vdso-absolute-reloc-v5-0-3a93791af1cf@linutronix.de?part=5