[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <6c03d212-775c-cddb-b0d0-d7b00571694b@ghiti.fr>
Date: Wed, 15 Jan 2020 15:48:18 -0500
From: Alexandre Ghiti <alexandre@...ti.fr>
To: Alexei Starovoitov <alexei.starovoitov@...il.com>,
Zong Li <zong.li@...ive.com>
Cc: Palmer Dabbelt <palmerdabbelt@...gle.com>,
Stephen Rothwell <sfr@...b.auug.org.au>,
Daniel Borkmann <daniel@...earbox.net>,
Alexei Starovoitov <ast@...nel.org>,
Network Development <netdev@...r.kernel.org>,
Linux-Next Mailing List <linux-next@...r.kernel.org>,
"linux-kernel@...r.kernel.org List" <linux-kernel@...r.kernel.org>,
ppc-dev <linuxppc-dev@...ts.ozlabs.org>,
linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>
Subject: Re: linux-next: build warning after merge of the bpf-next tree
On 1/14/20 6:23 AM, Alexei Starovoitov wrote:
> On Sun, Jan 12, 2020 at 8:33 PM Zong Li<zong.li@...ive.com> wrote:
>> I'm not quite familiar with btf, so I have no idea why there are two
>> weak symbols be added in 8580ac9404f6 ("bpf: Process in-kernel BTF")
> I can explain what these weak symbols are for, but that won't change
> the fact that compiler or linker are buggy. The weak symbols should work
> in all cases and compiler should pick correct relocation.
> In this case it sounds that compiler picked relative relocation and failed
> to reach zero from that address.
Sorry for the response delay: I now agree that there is nothing weird
about those
relocations. All compiler/linker I took a look at (arm64, ppc64 and
riscv64) correctly
emit an absolute relocation to the address 0 in case of a weak
unresolved symbol,
so there's no buggy compiler/linker.
And regarding ppc warning, the kernel being compiled as -pie, the
scripts looks
for absolute relocations which it considers as "bad", except for one
that is known
to be weak and that is ignored: I have just sent a patch to fix this
script so that weak
undefined symbol relocations are not considered as bad.
Thanks,
Alex
Powered by blists - more mailing lists