On Tue, Mar 7, 2017 at 3:07 AM, Jesper Dangaard Brouer <[email protected]> wrote: > On Mon, 6 Mar 2017 16:14:06 -0800 > Alexei Starovoitov via iovisor-dev <[email protected]> wrote: > >> On Mon, Mar 6, 2017 at 10:29 AM, Jesper Dangaard Brouer >> <[email protected]> wrote: >> > On Mon, 6 Mar 2017 09:11:46 -0800 >> > Alexei Starovoitov via iovisor-dev <[email protected]> wrote: >> > >> >> On Mon, Mar 6, 2017 at 3:53 AM, Jesper Dangaard Brouer >> >> <[email protected]> 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 <[email protected]> >> >> > 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 <[email protected]> >> >> > >> >> > 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. 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, but I suggest to upgrade llvm regardless, 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. >> 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. _______________________________________________ iovisor-dev mailing list [email protected] https://lists.iovisor.org/mailman/listinfo/iovisor-dev
