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 ? > I've never done it myself. Is there an easier way to answer my question: Q: how big is my eBPF program? I would actually (also) like to know the size of the JIT'ed asm code? -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer _______________________________________________ iovisor-dev mailing list [email protected] https://lists.iovisor.org/mailman/listinfo/iovisor-dev
