On 1/10/20 6:18 PM, Alexei Starovoitov wrote:
On Fri, Jan 10, 2020 at 2:28 PM Alexandre Ghiti <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.
Are you saying there is a warning for arm64 as well?
Nop.
Can ppc folks explain the above warning?
What does it mean "2 bad relocations"?
This is what I'd like to understand too, it is not clear in
the ppc tool that outputs this message why it is considered 'bad'.
The code is doing:
extern char __weak _binary__btf_vmlinux_bin_start[];
extern char __weak _binary__btf_vmlinux_bin_end[];
Since they are weak they should be zero when not defined.
What's the issue?
There likely is no issue, I just want to make sure those relocations
are legitimate and I want to understand what we should do with those.
At the moment arm64 does not relocate those at runtime and purely
ignore them: is this the right thing to do ?
