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
it will show section names, asm code and original C code
if compiled with -g
It's important to mention that .o is a normal elf file,
but the doc doesn't need to go into elf details.
> Is there an easier way to answer my question:
> Q: how big is my eBPF program?
in llvm-objdump output you'll see something like:
139: 85 00 00 00 01 00 00 00 call 1
140: b7 00 00 00 00 00 00 00 r0 = 0
141: 95 00 00 00 00 00 00 00 exit
so this particular program has 141 instructions.
> I would actually (also) like to know the size of the JIT'ed asm code?
that's practically impossible to know in advance, since hardening and
start address randomization will play a role.
Or use sysctl net.core.bpf_jit_enable=2
at load time which gives raw x86 hex.
_______________________________________________
iovisor-dev mailing list
[email protected]
https://lists.iovisor.org/mailman/listinfo/iovisor-dev
