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...
