From: Yao Zi <me@ziyao.cc>
To: "Maciej W. Rozycki" <macro@orcam.me.uk>
Cc: Nathan Chancellor <nathan@kernel.org>,
Ard Biesheuvel <ardb@kernel.org>,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
linux-mips@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] MIPS: tools: relocs: Ship a definition of R_MIPS_PC32
Date: Thu, 5 Feb 2026 08:26:30 +0000 [thread overview]
Message-ID: <aYRUNhoJ9ygNLYwF@pie> (raw)
In-Reply-To: <alpine.DEB.2.21.2602050110020.17548@angie.orcam.me.uk>
On Thu, Feb 05, 2026 at 01:26:39AM +0000, 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,
> as it's going to change as a commit is merged.
This commit has been in kbuild/kbuild-next for some time[1], and has
broken linux-next MIPS builds on my machine.
> Also can't you get the fix folded into the offending commit since it
> hasn't been merged yet?
I'm not the author of ff79d31eb536 ("mips: Add support for PC32
relocations in vmlinux"), and though it hasn't reached Linus' master,
it has been merged into kbuild-next.
I'm fine with it if the maintainer considers it necessary to squash
them together.
> Maciej
Thanks,
Yao Zi
[1]: https://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux.git/commit/?id=ff79d31eb536f6d87bcbc09287d54d5606bf6dbe
next prev parent reply other threads:[~2026-02-05 8:26 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-02 4:16 [PATCH] MIPS: tools: relocs: Ship a definition of R_MIPS_PC32 Yao Zi
2026-02-02 9:17 ` Ard Biesheuvel
2026-02-02 23:07 ` Nathan Chancellor
2026-02-03 3:56 ` Yao Zi
2026-02-03 12:31 ` Ard Biesheuvel
2026-02-05 1:26 ` Maciej W. Rozycki
2026-02-05 8:26 ` Yao Zi [this message]
2026-02-05 8:39 ` Ard Biesheuvel
2026-02-03 18:53 ` Nathan Chancellor
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aYRUNhoJ9ygNLYwF@pie \
--to=me@ziyao.cc \
--cc=ardb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=macro@orcam.me.uk \
--cc=nathan@kernel.org \
--cc=tsbogend@alpha.franken.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox