Re: linux-next: build warning after merge of the bpf-next tree

From: Alexandre Ghiti
Date: Sat Jan 11 2020 - 09:32:05 EST



On 1/10/20 7:20 PM, Palmer Dabbelt wrote:
On Fri, 10 Jan 2020 14:28:17 PST (-0800), alexandre@xxxxxxxx wrote:
Hi guys,

On 10/27/19 8:02 PM, Stephen Rothwell wrote:
Hi all,

On Fri, 18 Oct 2019 10:56:57 +1100 Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx> wrote:
Hi all,

After merging the bpf-next tree, today's linux-next build (powerpc
ppc64_defconfig) produced this warning:

WARNING: 2 bad relocations
c000000001998a48 R_PPC64_ADDR64 _binary__btf_vmlinux_bin_start
c000000001998a50 R_PPC64_ADDR64 _binary__btf_vmlinux_bin_end

Introduced by commit

ÂÂ 8580ac9404f6 ("bpf: Process in-kernel BTF")
This warning now appears in the net-next tree build.


I bump that thread up because Zong also noticed that 2 new relocations for
those symbols appeared in my riscv relocatable kernel branch following
that commit.

I also noticed 2 new relocations R_AARCH64_ABS64 appearing in arm64 kernel.

Those 2 weak undefined symbols have existed since commit
341dfcf8d78e ("btf: expose BTF info through sysfs") but this is the fact
to declare those symbols into btf.c that produced those relocations.

I'm not sure what this all means, but this is not something I expected
for riscv for
a kernel linked with -shared/-fpie. Maybe should we just leave them to
zero ?

I think that deserves a deeper look if someone understands all this
better than I do.

Can you give me a pointer to your tree and how to build a relocatable kernel?
Weak undefined symbols have the absolute value 0,


So according to you the 2 new relocations R_RISCV_64 are normal and should not
be modified at runtime right ?


but the kernel is linked at
an address such that 0 can't be reached by normal means. When I added support
to binutils for this I did it in a way that required almost no code --
essetially I just stopped dissallowing x0 as a possible base register for PCREL
relocations, which results in 0 always being accessible. I just wanted to get
the kernel to build again, so I didn't worry about chasing around all the
addressing modes. The PIC/PIE support generates different relocations and I
wouldn't be surprised if I just missed one (or more likely all) of them.

It's probably a simple fix, though I feel like every time I say that about the
linker I end up spending a month in there...

You can find it here:

https://github.com/AlexGhiti/riscv-linux/tree/int/alex/riscv_relocatable_v1

Zong fixed the bug introduced by those 2 new relocations and everything works
like a charm, so I'm not sure you have to dig in the linker :)

Alex