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? why is it useful to do readelf? and look at hex ? I've never done it myself. _______________________________________________ iovisor-dev mailing list [email protected] https://lists.iovisor.org/mailman/listinfo/iovisor-dev
