* llvm-objdump...
@ 2017-04-25 17:13 David Miller
2017-04-26 3:48 ` llvm-objdump Alexei Starovoitov
0 siblings, 1 reply; 6+ messages in thread
From: David Miller @ 2017-04-25 17:13 UTC (permalink / raw)
To: ast; +Cc: daniel, netdev
I think there are some endianness issues ;-)
davem@patience:~/src/GIT/net-next/tools/testing/selftests/bpf$ llvm-objdump -S x.o
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"
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: llvm-objdump...
2017-04-25 17:13 llvm-objdump David Miller
@ 2017-04-26 3:48 ` Alexei Starovoitov
2017-04-28 16:17 ` llvm-objdump David Miller
0 siblings, 1 reply; 6+ messages in thread
From: Alexei Starovoitov @ 2017-04-26 3:48 UTC (permalink / raw)
To: David Miller; +Cc: daniel, netdev
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...
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: llvm-objdump...
2017-04-26 3:48 ` llvm-objdump Alexei Starovoitov
@ 2017-04-28 16:17 ` David Miller
2017-04-28 16:22 ` llvm-objdump Alexei Starovoitov
0 siblings, 1 reply; 6+ messages in thread
From: David Miller @ 2017-04-28 16:17 UTC (permalink / raw)
To: ast; +Cc: daniel, netdev
From: Alexei Starovoitov <ast@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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: llvm-objdump...
2017-04-28 16:17 ` llvm-objdump David Miller
@ 2017-04-28 16:22 ` Alexei Starovoitov
2017-04-28 16:38 ` llvm-objdump David Miller
0 siblings, 1 reply; 6+ messages in thread
From: Alexei Starovoitov @ 2017-04-28 16:22 UTC (permalink / raw)
To: David Miller; +Cc: daniel, netdev
On 4/28/17 9:17 AM, David Miller wrote:
> Even if I give it -triple=bpfeb it emits immediates incorrectly.
>
> The bug is certainly in the insn field fetcher of the disassembler.
got it. so the binary looks correct, but disasm output is wrong?
Thanks! Looks like there is a bug there indeed.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: llvm-objdump...
2017-04-28 16:22 ` llvm-objdump Alexei Starovoitov
@ 2017-04-28 16:38 ` David Miller
2017-04-28 17:18 ` llvm-objdump Alexei Starovoitov
0 siblings, 1 reply; 6+ messages in thread
From: David Miller @ 2017-04-28 16:38 UTC (permalink / raw)
To: ast; +Cc: daniel, netdev
From: Alexei Starovoitov <ast@fb.com>
Date: Fri, 28 Apr 2017 09:22:32 -0700
> On 4/28/17 9:17 AM, David Miller wrote:
>> Even if I give it -triple=bpfeb it emits immediates incorrectly.
>>
>> The bug is certainly in the insn field fetcher of the disassembler.
>
> got it. so the binary looks correct, but disasm output is wrong?
F.e.
12: 07 70 00 00 00 00 00 06 r0 += 100663296
Should be "r0 += 6"
Yes.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: llvm-objdump...
2017-04-28 16:38 ` llvm-objdump David Miller
@ 2017-04-28 17:18 ` Alexei Starovoitov
0 siblings, 0 replies; 6+ messages in thread
From: Alexei Starovoitov @ 2017-04-28 17:18 UTC (permalink / raw)
To: David Miller; +Cc: daniel, netdev
On 4/28/17 9:38 AM, David Miller wrote:
> From: Alexei Starovoitov <ast@fb.com>
> Date: Fri, 28 Apr 2017 09:22:32 -0700
>
>> On 4/28/17 9:17 AM, David Miller wrote:
>>> Even if I give it -triple=bpfeb it emits immediates incorrectly.
>>>
>>> The bug is certainly in the insn field fetcher of the disassembler.
>>
>> got it. so the binary looks correct, but disasm output is wrong?
>
> F.e.
>
> 12: 07 70 00 00 00 00 00 06 r0 += 100663296
>
> Should be "r0 += 6"
Pushed the fix into the llvm trunk:
https://reviews.llvm.org/rL301653
if buildbots don't yell at me in the next few hours then it's
probably good.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-04-28 17:18 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-04-25 17:13 llvm-objdump David Miller
2017-04-26 3:48 ` llvm-objdump Alexei Starovoitov
2017-04-28 16:17 ` llvm-objdump David Miller
2017-04-28 16:22 ` llvm-objdump Alexei Starovoitov
2017-04-28 16:38 ` llvm-objdump David Miller
2017-04-28 17:18 ` llvm-objdump Alexei Starovoitov
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.