[llvm-dev] [iovisor-dev] [PATCH, BPF 4/5] BPF: Add 32-bit move patterns
Alexei Starovoitov via llvm-dev
llvm-dev at lists.llvm.org
Thu Jun 16 13:25:35 PDT 2016
On Thu, Jun 16, 2016 at 10:28 AM, Richard Henderson <rth at twiddle.net> wrote:
> On 06/15/2016 10:38 PM, Alexei Starovoitov wrote:
>> but before we go too far with new asm syntax like 'movw',
>> Do you want to revamp the whole thing?
>> imo the kernel verifier asm output is easier to read
>> due to being C-like and now more people understand it
>> vs what llvm bpf backend produces.
> While the kernel verifier format is ok for the 64-bit opcodes, I personally
> can't stand what it does for the 32-bit opcodes, e.g.
> (u32) r0 += (u32) r1
> That's not only unnecessarily verbose, it's bad C.
sure. we didn't have llvm producing 32-bit opcodes,
so that part was a quick hack.
Looking at your elfutils patch that does:
r%1$d = (u32)r%1$d + (u32)r%2$d
that totally makes sense to me.
I can change kernel to do that as well.
What I'm suggesting is to teach llvm backend to output that
elfutils style as well.
>> Right now we have two asms: what kernel verifier prints
>> and llvm bpf asm output. Kernel side we cannot drastically
>> change anymore, but minor changes should be ok if it
>> helps to converge to one common bpf asm syntax.
> Why, is the kernel verifier output considered part of the abi now? That seems
> like an odd position to take.
> I also have a disassembler written for elfutils, so that it ties in nicely with
> objdump. I started with tweaks to the kernel output (which can be seen in the
> post I quoted earlier), but have since changed to use the llvm disassembly (and
> have not yet re-posted).
what was posted in elfutils is preferred to me.
We can cleanup kernel output for 32-bit like you did,
but we cannot change it drastically, since plenty of users already
learned to understand the verifier output which especially important
in case of program rejects.
More information about the llvm-dev