From: Alexei Starovoitov <a...@fb.com>
Date: Tue, 25 Apr 2017 20:48:52 -0700
> On 4/25/17 10:13 AM, David Miller wrote:
>>
>> I think there are some endianness issues ;-)
>>
>> davem@patience:~/src/GIT/net-next/tools/testing/selftests/bpf$
>> llvm-objdump -S x.o
>
> nice host name ;)
>
>> x.o: file format ELF64-BPF
>>
>> Disassembly of section test1:
>> process:
>> 0: b7 00 00 00 00 00 00 02 r0 = 33554432
>> 1: 61 21 00 50 00 00 00 00 r1 = *(u32 *)(r2 + 20480)
>>
>> That first instruction should be "r0 = 2"
>
> hmm. I haven't tested it on big endian.
> When last time s390 folks tested samples/bpf with llvm we didn't even
> have automatic -march=bpf in llvm, so they used -march=bpfeb.
> There was no llvm-objdump support either.
>
> llvm side does this:
> tatic Triple::ArchType parseBPFArch(StringRef ArchName) {
> if (ArchName.equals("bpf")) {
> if (sys::IsLittleEndianHost)
> return Triple::bpfel;
> else
> return Triple::bpfeb;
> } else if (ArchName.equals("bpf_be") || ArchName.equals("bpfeb")) {
> return Triple::bpfeb;
> } else if (ArchName.equals("bpf_le") || ArchName.equals("bpfel")) {
> return Triple::bpfel;
>
> It works for clang and for llvm.
> I thought llvm-objdump should infer triple from elf file
> and do the 'right thing'... hmm
>
> could you please test it with -g and see whether dwarf is still
> correct in .o ?
> llvm-objdump -S should print original C code next to asm.
> Hope bpf dwarf is not broken on big-endian...
Even if I give it -triple=bpfeb it emits immediates incorrectly.
The bug is certainly in the insn field fetcher of the disassembler.
