[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <376f9737-f9a4-da68-8b7f-26020021613c@isovalent.com>
Date: Tue, 17 Jan 2023 14:41:06 +0000
From: Quentin Monnet <quentin@...valent.com>
To: Christophe Leroy <christophe.leroy@...roup.eu>,
Tonghao Zhang <tong@...ragraf.org>
Cc: Daniel Borkmann <daniel@...earbox.net>,
"bpf@...r.kernel.org" <bpf@...r.kernel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.or"
<linux-arm-kernel@...ts.infradead.or>,
"loongarch@...ts.linux.dev" <loongarch@...ts.linux.dev>,
"linux-mips@...r.kernel.org" <linux-mips@...r.kernel.org>,
"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
"linux-riscv@...ts.infradead.org" <linux-riscv@...ts.infradead.org>,
"linux-s390@...r.kernel.org" <linux-s390@...r.kernel.org>,
"sparclinux@...r.kernel.org" <sparclinux@...r.kernel.org>,
Hao Luo <haoluo@...gle.com>,
John Fastabend <john.fastabend@...il.com>,
Alexei Starovoitov <ast@...nel.org>,
Andrii Nakryiko <andrii@...nel.org>,
Song Liu <song@...nel.org>,
Stanislav Fomichev <sdf@...gle.com>,
Jiri Olsa <jolsa@...nel.org>, Hou Tao <houtao1@...wei.com>,
KP Singh <kpsingh@...nel.org>, Yonghong Song <yhs@...com>,
Martin KaFai Lau <martin.lau@...ux.dev>,
"naveen.n.rao@...ux.ibm.com" <naveen.n.rao@...ux.ibm.com>,
"mpe@...erman.id.au" <mpe@...erman.id.au>
Subject: Re: [bpf-next v2] bpf: drop deprecated bpf_jit_enable == 2
2023-01-17 14:25 UTC+0000 ~ Christophe Leroy <christophe.leroy@...roup.eu>
>
>
> Le 17/01/2023 à 15:18, Tonghao Zhang a écrit :
>>
>>
>>> On Jan 17, 2023, at 7:36 PM, Christophe Leroy <christophe.leroy@...roup.eu> wrote:
>>>
>>>
>>>
>>> Le 17/01/2023 à 08:30, Christophe Leroy a écrit :
>>>>
>>>>
>>>> Le 17/01/2023 à 06:30, Tonghao Zhang a écrit :
>>>>>
>>>>>
>>>>>> On Jan 9, 2023, at 4:15 PM, Christophe Leroy
>>>>>> <christophe.leroy@...roup.eu> wrote:
[...]
>>>>>> Sure I will try to test bpftool again in the coming days.
>>>>>>
>>>>>> Previous discussion about that subject is here:
>>>>>> https://patchwork.kernel.org/project/linux-riscv/patch/20210415093250.3391257-1-Jianlin.Lv@arm.com/#24176847=
Christophe, apologies from dropping the discussion the last time, it
seems your last message on that thread didn't make it to my inbox at the
time :/. Thanks a lot for looking into that again!
>>>>> Hi Christophe
>>>>> Any progress? We discuss to deprecate the bpf_jit_enable == 2 in 2021,
>>>>> but bpftool can not run on powerpc.
>>>>> Now can we fix this issue?
>>>>
>>>> Hi Tong,
>>>>
>>>> I have started to look at it but I don't have any fruitfull feedback yet.
>>>
>>> Hi Again,
>>>
>>> I tested again, the problem is still the same as one year ago:
>>>
>>> root@...ip:~# ./bpftool prog
>>> libbpf: elf: endianness mismatch in pid_iter_bpf.
>> It seem to be not right ehdr->e_ident[EI_DATA]. Do we can print the real value?
>> /*
>> * e_ident[EI_DATA]
>> */
>> #define ELFDATANONE 0
>> #define ELFDATA2LSB 1
>> #define ELFDATA2MSB 2
>> #define ELFDATANUM 3
>>
>> bpf_object__elf_init:
>> obj->efile.ehdr = ehdr = elf64_getehdr(elf);
>>
>>> libbpf: failed to initialize skeleton BPF object 'pid_iter_bpf': -4003
>>> Error: failed to open PID iterator skeleton
>>>
>>> root@...ip:~# uname -a
>>> Linux vgoip 6.2.0-rc3-02596-g1c2c9c13e256 #242 PREEMPT Tue Jan 17
>>> 09:36:08 CET 2023 ppc GNU/Linux
>> On my pc, elf is little endian.
>> # readelf -h tools/bpf/bpftool/pid_iter.bpf.o
>> ELF Header:
>> Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
>> Class: ELF64
>> Data: 2's complement, little endian # x86_64
>> Version: 1 (current)
>> OS/ABI: UNIX - System V
>> ABI Version: 0
>> Type: REL (Relocatable file)
>> Machine: Linux BPF
>> Version: 0x1
>> Entry point address: 0x0
>> Start of program headers: 0 (bytes into file)
>> Start of section headers: 64832 (bytes into file)
>> Flags: 0x0
>> Size of this header: 64 (bytes)
>> Size of program headers: 0 (bytes)
>> Number of program headers: 0
>> Size of section headers: 64 (bytes)
>> Number of section headers: 13
>> Section header string table index: 1
>>
>
> Yes, must be something wrong with the build, I get same as you :
>
> $ LANG= readelf -h pid_iter.bpf.o
> ELF Header:
> Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
> Class: ELF64
> Data: 2's complement, little endian
> Version: 1 (current)
> OS/ABI: UNIX - System V
> ABI Version: 0
> Type: REL (Relocatable file)
> Machine: Linux BPF
> Version: 0x1
> Entry point address: 0x0
> Start of program headers: 0 (bytes into file)
> Start of section headers: 34704 (bytes into file)
> Flags: 0x0
> Size of this header: 64 (bytes)
> Size of program headers: 0 (bytes)
> Number of program headers: 0
> Size of section headers: 64 (bytes)
> Number of section headers: 13
> Section header string table index: 1
>
>
> Whereas I expect the same as bpftool I suppose, which is :
>
> $ LANG= readelf -h bpftool
> ELF Header:
> Magic: 7f 45 4c 46 01 02 01 00 00 00 00 00 00 00 00 00
> Class: ELF32
> Data: 2's complement, big endian
> Version: 1 (current)
> OS/ABI: UNIX - System V
> ABI Version: 0
> Type: EXEC (Executable file)
> Machine: PowerPC
> Version: 0x1
> Entry point address: 0x100027d0
> Start of program headers: 52 (bytes into file)
> Start of section headers: 1842896 (bytes into file)
> Flags: 0x0
> Size of this header: 52 (bytes)
> Size of program headers: 32 (bytes)
> Number of program headers: 9
> Size of section headers: 40 (bytes)
> Number of section headers: 39
> Section header string table index: 38
>
pid_iter.bpf.o should be generated from that command in bpftool's Makefile:
$(OUTPUT)%.bpf.o: skeleton/%.bpf.c $(OUTPUT)vmlinux.h \
$(LIBBPF_BOOTSTRAP)
$(QUIET_CLANG)$(CLANG) \
-I$(or $(OUTPUT),.) \
-I$(srctree)/tools/include/uapi/ \
-I$(LIBBPF_BOOTSTRAP_INCLUDE) \
-g -O2 -Wall -fno-stack-protector \
-target bpf -c $< -o $@
My understanding is that "-target bpf" is supposed to pick the
endianness for the host (see "llc --version | grep bpf". If that's not
the case, could you please try to turn that into '-target bpfeb' in the
Makefile instead? I'd be curious to see if it helps.
Quentin
Powered by blists - more mailing lists