On Thu, Jun 16, 2016 at 10:28 AM, Richard Henderson <[email protected]> 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. _______________________________________________ iovisor-dev mailing list [email protected] https://lists.iovisor.org/mailman/listinfo/iovisor-dev
