On Tue, 7 Mar 2017 07:57:00 -0800 Alexei Starovoitov via iovisor-dev <iovisor-dev@lists.iovisor.org> wrote:
> On Tue, Mar 7, 2017 at 3:07 AM, Jesper Dangaard Brouer > <jbro...@redhat.com> wrote: > > On Mon, 6 Mar 2017 16:14:06 -0800 > > Alexei Starovoitov via iovisor-dev <iovisor-dev@lists.iovisor.org> wrote: > > > >> On Mon, Mar 6, 2017 at 10:29 AM, Jesper Dangaard Brouer > >> <jbro...@redhat.com> wrote: > >> > On Mon, 6 Mar 2017 09:11:46 -0800 > >> > Alexei Starovoitov via iovisor-dev <iovisor-dev@lists.iovisor.org> wrote: > >> > > >> >> On Mon, Mar 6, 2017 at 3:53 AM, Jesper Dangaard Brouer > >> >> <jbro...@redhat.com> wrote: > >> >> > Hi All, > >> >> > > >> >> > I've added a section to my eBPF documentation, about how to read the > >> >> > eBPF generated ELF binary, and deduct the size of the compiled program > >> >> > (mostly for kernel/samples/bpf). > >> >> > > >> >> > https://prototype-kernel.readthedocs.io/en/latest/bpf/troubleshooting.html#elf-binary > >> >> > https://github.com/netoptimizer/prototype-kernel/commit/079352102cb0ba > >> >> > > >> >> > Can someone validate what I've saying is true? (commit inlined below > >> >> > sign, to make is as easy as possible for people to correct me). > >> >> > > >> >> > And anything else users can use the readelf output for? > >> >> > > >> >> > -- > >> >> > Best regards, > >> >> > Jesper Dangaard Brouer > >> >> > MSc.CS, Principal Kernel Engineer at Red Hat > >> >> > LinkedIn: http://www.linkedin.com/in/brouer > >> >> > > >> >> > commit 079352102cb0ba12141ecd28c216ec5ac5290192 > >> >> > Author: Jesper Dangaard Brouer <bro...@redhat.com> > >> >> > Date: Fri Feb 24 12:10:45 2017 +0100 > >> >> > > >> >> > doc: eBPF describe howto read the eBPF generated ELF binary > >> >> > > >> >> > Signed-off-by: Jesper Dangaard Brouer <bro...@redhat.com> > >> >> > > >> >> > diff --git a/kernel/Documentation/bpf/troubleshooting.rst > >> >> > b/kernel/Documentation/bpf/troubleshooting.rst > >> >> > index b6f3b6fe9501..39ebffae4142 100644 > >> >> > --- a/kernel/Documentation/bpf/troubleshooting.rst > >> >> > +++ b/kernel/Documentation/bpf/troubleshooting.rst > >> >> > @@ -15,6 +15,41 @@ see system call `setrlimit(2)`_. > >> >> > The ``bpf_create_map`` call will return errno EPERM (Operation not > >> >> > permitted) when the RLIMIT_MEMLOCK memory size limit is exceeded. > >> >> > > >> >> > - > >> >> > .. _setrlimit(2): > >> >> > http://man7.org/linux/man-pages/man2/setrlimit.2.html > >> >> > > >> >> > +ELF binary > >> >> > +========== > >> >> > + > >> >> > +The binary containing the eBPF program, which got generated by the > >> >> > +LLVM compiler, is an ELF binary. For samples/bpf/ this is the file > >> >> > +named xxx_kern.o. > >> >> > + > >> >> > +To answer questions like how big is my eBPF program, it is possible > >> >> > to > >> >> > +use a tool like ``readelf``. :: > >> >> > + > >> >> > + $ readelf -SW xdp_ddos01_blacklist_kern.o > >> >> > + There are 8 section headers, starting at offset 0x398: > >> >> > + > >> >> > + Section Headers: > >> >> > + [Nr] Name Type Address Off Size ES > >> >> > Flg Lk Inf Al > >> >> > + [ 0] NULL 0000000000000000 000000 000000 00 > >> >> > 0 0 0 > >> >> > + [ 1] .strtab STRTAB 0000000000000000 000320 000072 00 > >> >> > 0 0 1 > >> >> > + [ 2] .text PROGBITS 0000000000000000 000040 000000 00 > >> >> > AX 0 0 4 > >> >> > + [ 3] xdp_prog PROGBITS 0000000000000000 000040 0001b8 00 > >> >> > AX 0 0 8 > >> >> > + [ 4] .relxdp_prog REL 0000000000000000 000300 000020 10 > >> >> > 7 3 8 > >> >> > + [ 5] maps PROGBITS 0000000000000000 0001f8 000028 00 > >> >> > WA 0 0 4 > >> >> > + [ 6] license PROGBITS 0000000000000000 000220 000004 00 > >> >> > WA 0 0 1 > >> >> > + [ 7] .symtab SYMTAB 0000000000000000 000228 0000d8 18 > >> >> > 1 5 8 > >> >> > + Key to Flags: > >> >> > + W (write), A (alloc), X (execute), M (merge), S (strings) > >> >> > + I (info), L (link order), G (group), T (TLS), E (exclude), x > >> >> > (unknown) > >> >> > + O (extra OS processing required) o (OS specific), p (processor > >> >> > specific) > >> >> > + > >> >> > +From the output, we can see the programmer choose to name the XDP > >> >> > +program section "xdp_prog". From this line ([ 3]) the size column > >> >> > +shows the size 0001b8 in hex, which is easily converted on the > >> >> > cmdline > >> >> > +to 440 bytes:: > >> >> > + > >> >> > + $ echo $((0x0001b8)) > >> >> > + 440 > >> >> > >> >> hmm. i think instead of clarifying bpf elf output is doing the opposite. > >> >> at least i'm completely lost in the above text. > >> >> What all of the above suppose to mean? > >> > > >> > That what I'm implicit asking you ;-) > >> > > >> >> why is it useful to do readelf? and look at hex ? > >> > > >> > What other tools exists to help me understand the contents of the LLVM > >> > compiled binary _kern.o ? > >> > >> The best is to use > >> llvm-objdump -S prog_kern.o > > > > Hmmm, what version of LLVM have the -S option? > > > > $ llvm-objdump -S xdp_ddos01_blacklist_kern.o > > llvm-objdump: Unknown command line argument '-S'. Try: 'llvm-objdump -help' > > llvm-objdump: Did you mean '-D'? > > > > $ llvm-objdump --version | egrep 'version|bpf' > > LLVM version 3.8.1 > > bpf - BPF (host endian) > > bpfeb - BPF (big endian) > > bpfel - BPF (little endian) > > > > I would really like some command tool, to inspect eBPF-ELF program > > with, available in a distro version, in this case Fedora 25. > > f25 takes an arbitrary snapshot of llvm and kernel in time. > if we try to document that snapshot, we should call it 'bpf on f25'. > It's not suitable for generic doc which imo should talk about > the latest kernel and the latest tools always. > There can be a history of which features appeared in > different kernel versions. Like we do in bcc docs. True, we don't want this doc to be come distro specific. I do believe we need to doc the history of LLVM to give users a chance to get started with eBPF. > As far as -S flag missing in early version... > the -d flag will print the same when there is no > debug info in the elf file, Using -d gives me: $ llvm-objdump -d xdp_ddos01_blacklist_kern.o xdp_ddos01_blacklist_kern.o: file format ELF64-unknown LLVM ERROR: can't find target: : error: unable to get target for 'unknown-unknown-unknown', see --version and --triple. Doing what it tells me, get me one step further: $ llvm-objdump -triple bpf -d xdp_ddos01_blacklist_kern.o xdp_ddos01_blacklist_kern.o: file format ELF64-unknown LLVM ERROR: error: no disassembler for target bpf What other options can I use for LLVM 3.8.1, that can produce something? > but I suggest to upgrade llvm regardless, p.s. my compile from latest git tree unfortunately died at :-( [ 98%] Built target llvm-xray > since 3.8 doesn't support debug info at all and users have > no way of knowing which C code compiles to which bpf asm > (unless they are compiler experts and can reverse engineer themself) > > >> it will show section names, asm code and original C code > >> if compiled with -g > > > > And the option -g is supplied to the CLANG program (not LLC). > > of course. front-end(clang) is the one emitting debug into IR. > If there is no debug in there backend(llc) cannot help. I was just stating the obvious (as other people might find this on Google later ;-)) > >> It's important to mention that .o is a normal elf file, > >> but the doc doesn't need to go into elf details. > > I suggest to trim down this 'readelf' section of the doc, > since it has a bunch of info that doesn't help to understand > how bpf elf is created and part of typical elf verbosity. > Like strtab, symtab, flags. > I also suggest to replace it with 'llvm-objdump -h file.o' > since it prints the same info as 'readelf -SW' > but less verbose. Good idea to instead describe use of: 'llvm-objdump -h file.o' -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer _______________________________________________ iovisor-dev mailing list iovisor-dev@lists.iovisor.org https://lists.iovisor.org/mailman/listinfo/iovisor-dev
