Re: [PATCH] MIPS: tools: relocs: Ship a definition of R_MIPS_PC32

["Ard Biesheuvel" <ardb@kernel.org>]

On Thu, 5 Feb 2026, at 02:26, Maciej W. Rozycki wrote:
> On Tue, 3 Feb 2026, Yao Zi wrote:
>
>> > I interpret that to mean that the kallsyms patch should work fine since
>> > the toolchain can handle these relocations? It is just building the
>> > relocs tool against an older glibc or musl that does not have the
>> > R_MIPS_PC32 definition that is broken? Or am I misunderstanding
>> > something?
>> 
>> Yes, this patch is only meant to fix building of relocs tool. I don't
>> think there are problems about toolchain supporting since R_MIPS_PC32
>> has been in binutils for a long time, as Nathan found, since 2004. The
>
>  Since Y2K to be exact:
>
> commit bb2d6cd7b19cd82313963d2d878a94e6e85a38b6
> Author: Geoffrey Keating <geoffk@geoffk.org>
> Date:   Sat Mar 11 02:16:25 2000 +0000
>
> [...]
>     In include/elf:
>     	* mips.h: Add R_MIPS_GNU_REL_HI16, R_MIPS_GNU_REL_LO16,
>      	R_MIPS_GNU_REL16_S2, R_MIPS_PC64 and R_MIPS_PC32 relocation
>      	numbers.
>
>> situation is that it's likely to have a toolchain supporting
>> R_MIPS_PC32, while elf.h on the build machine doesn't have its
>> definition. And after ff79d31eb536 ("mips: Add support for PC32
>> relocations in vmlinux"), the relocs tool started to require a
>> definition of R_MIPS_PC32 to build.
>
>  But where does ff79d31eb536 come from?  I can't see it on Linus's master 
> and you can't refer an SHA-1 ID from another repo in a 'Fixes:' tag AFAIK, 

Yes, you can, as long as the owner of the tree does not rebase.