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

From: Ard Biesheuvel

Date: Thu Feb 05 2026 - 03:40:03 EST




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@xxxxxxxxxx>
> 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.