From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Hemminger Subject: Re: [PATCH] tc, bpf: add option to dump bpf verifier as C program fragment Date: Wed, 20 Jun 2018 09:40:35 -0700 Message-ID: <20180620094035.45ba0239@xeon-e3> References: <1529225321-15429-1-git-send-email-ophirmu@mellanox.com> <20180618131842.7b4d259f@cakuba.netronome.com> <30ac6974-a434-926b-5749-25c594e5841c@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: David Ahern , Jakub Kicinski , Ophir Munk , netdev@vger.kernel.org, Thomas Monjalon , Olga Shern , ast@kernel.org To: Daniel Borkmann Return-path: Received: from mail-pl0-f65.google.com ([209.85.160.65]:38564 "EHLO mail-pl0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932082AbeFTQko (ORCPT ); Wed, 20 Jun 2018 12:40:44 -0400 Received: by mail-pl0-f65.google.com with SMTP id d10-v6so84822plo.5 for ; Wed, 20 Jun 2018 09:40:44 -0700 (PDT) In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: On Wed, 20 Jun 2018 00:13:52 +0200 Daniel Borkmann wrote: > On 06/18/2018 11:44 PM, David Ahern wrote: > > On 6/18/18 2:18 PM, Jakub Kicinski wrote: > >> On Sun, 17 Jun 2018 08:48:41 +0000, Ophir Munk wrote: > >>> Similar to cbpf used within tcpdump utility with a "-d" option to dump > >>> the compiled packet-matching code in a human readable form - tc has the > >>> "verbose" option to dump ebpf verifier output. > >>> Another useful option of cbpf using tcpdump "-dd" option is to dump > >>> packet-matching code a C program fragment. Similar to this - this commit > >>> adds a new tc ebpf option named "code" to dump ebpf verifier as C program > >>> fragment. > >>> > >>> Existing "verbose" option sample output: > >>> > >>> Verifier analysis: > >>> 0: (61) r2 = *(u32 *)(r1 +52) > >>> 1: (18) r3 = 0xdeadbeef > >>> 3: (63) *(u32 *)(r10 -4) = r3 > >>> . > >>> . > >>> 11: (63) *(u32 *)(r1 +52) = r2 > >>> 12: (18) r0 = 0xffffffff > >>> 14: (95) exit > >>> > >>> New "code" option sample output: > >>> > >>> /* struct bpf_insn cls_q_code[] = { */ > >>> {0x61, 2, 1, 52, 0x00000000}, > >>> {0x18, 3, 0, 0, 0xdeadbeef}, > >>> {0x00, 0, 0, 0, 0x00000000}, > >>> . > >>> . > >>> {0x63, 1, 2, 52, 0x00000000}, > >>> {0x18, 0, 0, 0, 0xffffffff}, > >>> {0x00, 0, 0, 0, 0x00000000}, > >>> {0x95, 0, 0, 0, 0x00000000}, > >>> > >>> Signed-off-by: Ophir Munk > >> > >> Hmm... printing C arrays looks like hacky integration with some C > >> code... Would you not be better served by simply using libbpf in > >> whatever is consuming this output? > > > > I was thinking the same. bpftool would provide options too -- print the > > above, print in macro encodings and verifier. I gave an example of this > > side by side dump at netconf 2.1. Does not look like the slides made it > > online; see attached. > > +1, I would also doubt that this adds a lot in terms of debuggability > when you're trying to load an object file with thousands of insns. Better > way would be to use llvm-objdump on the obj file to get to the annotated > disassembly, see also example in [0]. A .o to .c converter is wip for > libbpf/bpftool as presented in [1], which should provide the flexibility > to embedd an obj file. > > Cheers, > Daniel > > [0] http://cilium.readthedocs.io/en/latest/bpf/#llvm > [1] http://vger.kernel.org/netconf2018_files/AlexeiStarovoitov_netconf2018.pdf page 22 I am going to not accept this for now. Please respin for iproute2 next if you think bpftool won't be able to handle this.