Re: [iovisor-dev] Describing howto read the eBPF generated ELF binary
On Tue, Mar 07, 2017 at 10:13:13PM +0100, Jesper Dangaard Brouer wrote: > On Tue, 7 Mar 2017 21:54:42 +0100 > Jesper Dangaard Brouer wrote: > > > > 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' > > Fixed: > https://github.com/netoptimizer/prototype-kernel/commit/c5cf59ff9a9b > > https://prototype-kernel.readthedocs.io/en/latest/bpf/troubleshooting.html#elf-binary looks good. Thanks! > $ 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? hmm. I don't have 3.8 around anymore. I guess it was fixed in 3.9 or 4.0 ___ iovisor-dev mailing list iovisor-dev@lists.iovisor.org https://lists.iovisor.org/mailman/listinfo/iovisor-dev
Re: [iovisor-dev] Describing howto read the eBPF generated ELF binary
On Tue, 7 Mar 2017 21:54:42 +0100 Jesper Dangaard Brouer wrote: > > 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' Fixed: https://github.com/netoptimizer/prototype-kernel/commit/c5cf59ff9a9b https://prototype-kernel.readthedocs.io/en/latest/bpf/troubleshooting.html#elf-binary -- 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
Re: [iovisor-dev] Describing howto read the eBPF generated ELF binary
On Tue, 7 Mar 2017 07:57:00 -0800 Alexei Starovoitov via iovisor-dev wrote: > On Tue, Mar 7, 2017 at 3:07 AM, Jesper Dangaard Brouer > wrote: > > On Mon, 6 Mar 2017 16:14:06 -0800 > > Alexei Starovoitov via iovisor-dev wrote: > > > >> On Mon, Mar 6, 2017 at 10:29 AM, Jesper Dangaard Brouer > >> wrote: > >> > On Mon, 6 Mar 2017 09:11:46 -0800 > >> > Alexei Starovoitov via iovisor-dev wrote: > >> > > >> >> On Mon, Mar 6, 2017 at 3:53 AM, Jesper Dangaard Brouer > >> >> 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 > >> >> > 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 > >> >> > > >> >> > 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 OffSize ES > >> >> > Flg Lk Inf Al > >> >> > + [ 0]NULL 00 00 00 > >> >> >0 0 0 > >> >> > + [ 1] .strtabSTRTAB 000320 72 00 > >> >> >0 0 1 > >> >> > + [ 2] .text PROGBITS 40 00 00 > >> >> > AX 0 0 4 > >> >> > + [ 3] xdp_prog PROGBITS 40 0001b8 00 > >> >> > AX 0 0 8 > >> >> > + [ 4] .relxdp_prog REL 000300 20 10 > >> >> >7 3 8 > >> >> > + [ 5] maps PROGBITS 0001f8 28 00 > >> >> > WA 0 0 4 > >> >> > + [ 6] licensePROGBITS 000220 04 00 > >> >> > WA 0 0 1 > >> >> > + [ 7] .symtabSYMTAB 000228 d8 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
Re: [iovisor-dev] Describing howto read the eBPF generated ELF binary
On Tue, Mar 7, 2017 at 3:07 AM, Jesper Dangaard Brouer wrote: > On Mon, 6 Mar 2017 16:14:06 -0800 > Alexei Starovoitov via iovisor-dev wrote: > >> On Mon, Mar 6, 2017 at 10:29 AM, Jesper Dangaard Brouer >> wrote: >> > On Mon, 6 Mar 2017 09:11:46 -0800 >> > Alexei Starovoitov via iovisor-dev wrote: >> > >> >> On Mon, Mar 6, 2017 at 3:53 AM, Jesper Dangaard Brouer >> >> 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 >> >> > 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 >> >> > >> >> > 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 OffSize ES Flg >> >> > Lk Inf Al >> >> > + [ 0]NULL 00 00 00 >> >> > 0 0 0 >> >> > + [ 1] .strtabSTRTAB 000320 72 00 >> >> > 0 0 1 >> >> > + [ 2] .text PROGBITS 40 00 00 AX >> >> > 0 0 4 >> >> > + [ 3] xdp_prog PROGBITS 40 0001b8 00 AX >> >> > 0 0 8 >> >> > + [ 4] .relxdp_prog REL 000300 20 10 >> >> > 7 3 8 >> >> > + [ 5] maps PROGBITS 0001f8 28 00 WA >> >> > 0 0 4 >> >> > + [ 6] licensePROGBITS 000220 04 00 WA >> >> > 0 0 1 >> >> > + [ 7] .symtabSYMTAB 000228 d8 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
Re: [iovisor-dev] Describing howto read the eBPF generated ELF binary
On Tue, 7 Mar 2017 12:07:40 +0100 Jesper Dangaard Brouer via iovisor-dev wrote: > On Mon, 6 Mar 2017 16:14:06 -0800 > Alexei Starovoitov via iovisor-dev wrote: > > > On Mon, Mar 6, 2017 at 10:29 AM, Jesper Dangaard Brouer > > wrote: > > > On Mon, 6 Mar 2017 09:11:46 -0800 > > > Alexei Starovoitov via iovisor-dev wrote: > > > > > >> On Mon, Mar 6, 2017 at 3:53 AM, Jesper Dangaard Brouer > > >> 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 > > >> > 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 > > >> > > > >> > 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 OffSize ES > > >> > Flg Lk Inf Al > > >> > + [ 0]NULL 00 00 00 > > >> > 0 0 0 > > >> > + [ 1] .strtabSTRTAB 000320 72 00 > > >> > 0 0 1 > > >> > + [ 2] .text PROGBITS 40 00 00 > > >> > AX 0 0 4 > > >> > + [ 3] xdp_prog PROGBITS 40 0001b8 00 > > >> > AX 0 0 8 > > >> > + [ 4] .relxdp_prog REL 000300 20 10 > > >> > 7 3 8 > > >> > + [ 5] maps PROGBITS 0001f8 28 00 > > >> > WA 0 0 4 > > >> > + [ 6] licensePROGBITS 000220 04 00 > > >> > WA 0 0 1 > > >> > + [ 7] .symtabSYMTAB 000228 d8 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? Added a section, so I/we will document this feature later: https://github.com/netoptimizer/prototype-kernel/commit/8cec9cebb7b https://prototype-kernel.readthedocs.io/en/latest/bpf/troubleshooting.h
Re: [iovisor-dev] Describing howto read the eBPF generated ELF binary
On Tue, 07 Mar 2017 12:40:03 +0100 Daniel Borkmann wrote: > On 03/07/2017 12:07 PM, Jesper Dangaard Brouer via iovisor-dev wrote: > > On Mon, 6 Mar 2017 16:14:06 -0800 > > Alexei Starovoitov via iovisor-dev wrote: > [...] > >> 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. > > > > The sysctl adjusting sounds interesting: > > > > sysctl net.core.bpf_jit_enable=2 > > > > What is below "proglen=335" the JIT'ed asm-code size? > > It's in bpf_jit_dump(): proglen is the len of opcode sequence generated > and flen is the number of bpf insns. You can use tools/net/bpf_jit_disasm.c > to disassemble that output. bpf_jit_disasm -o will dump the related opcodes > as well. Thanks for input, added: https://github.com/netoptimizer/prototype-kernel/commit/0b31532f42cd8 > > flen=55 proglen=335 pass=4 image=a0006820 from=xdp_ddos01_blac > > pid=1 > > JIT code: : 55 48 89 e5 48 81 ec 28 02 00 00 48 89 9d d8 fd > > JIT code: 0010: ff ff 4c 89 ad e0 fd ff ff 4c 89 b5 e8 fd ff ff > > JIT code: 0020: 4c 89 bd f0 fd ff ff 31 c0 48 89 85 f8 fd ff ff > > JIT code: 0030: bb 02 00 00 00 48 8b 77 08 48 8b 7f 00 48 89 fa > > JIT code: 0040: 48 83 c2 0e 48 39 f2 0f 87 e1 00 00 00 48 0f b6 > > JIT code: 0050: 4f 0c 48 0f b6 57 0d 48 c1 e2 08 48 09 ca 48 89 > > JIT code: 0060: d1 48 81 e1 ff 00 00 00 41 b8 06 00 00 00 49 39 > > JIT code: 0070: c8 0f 87 b7 00 00 00 48 81 fa 88 a8 00 00 74 0e > > JIT code: 0080: b9 0e 00 00 00 48 81 fa 81 00 00 00 75 1a 48 89 > > JIT code: 0090: fa 48 83 c2 12 48 39 f2 0f 87 90 00 00 00 b9 12 > > JIT code: 00a0: 00 00 00 48 0f b7 57 10 bb 02 00 00 00 48 81 e2 > > JIT code: 00b0: ff ff 00 00 48 83 fa 08 75 49 48 01 cf 31 db 48 > > JIT code: 00c0: 89 fa 48 83 c2 14 48 39 f2 77 38 8b 7f 0c 89 7d > > JIT code: 00d0: fc 48 89 ee 48 83 c6 fc 48 bf 00 9c 24 5f 07 88 > > JIT code: 00e0: ff ff e8 29 cd 13 e1 bb 02 00 00 00 48 83 f8 00 > > JIT code: 00f0: 74 11 48 8b 78 00 48 83 c7 01 48 89 78 00 bb 01 > > JIT code: 0100: 00 00 00 89 5d f8 48 89 ee 48 83 c6 f8 48 bf c0 > > JIT code: 0110: 76 12 13 04 88 ff ff e8 f4 cc 13 e1 48 83 f8 00 > > JIT code: 0120: 74 0c 48 8b 78 00 48 83 c7 01 48 89 78 00 48 89 > > JIT code: 0130: d8 48 8b 9d d8 fd ff ff 4c 8b ad e0 fd ff ff 4c > > JIT code: 0140: 8b b5 e8 fd ff ff 4c 8b bd f0 fd ff ff c9 c3 > > > > $ echo $((0x140)) > > 320 > > $ echo $((0x140 + 15)) > > 335 > > > > Using same example code, thus BPF instructions-size was 440 bytes, so > > the JIT'ed code size does get smaller. > > > -- 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
Re: [iovisor-dev] Describing howto read the eBPF generated ELF binary
On 03/07/2017 12:07 PM, Jesper Dangaard Brouer via iovisor-dev wrote: On Mon, 6 Mar 2017 16:14:06 -0800 Alexei Starovoitov via iovisor-dev wrote: [...] 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. The sysctl adjusting sounds interesting: sysctl net.core.bpf_jit_enable=2 What is below "proglen=335" the JIT'ed asm-code size? It's in bpf_jit_dump(): proglen is the len of opcode sequence generated and flen is the number of bpf insns. You can use tools/net/bpf_jit_disasm.c to disassemble that output. bpf_jit_disasm -o will dump the related opcodes as well. flen=55 proglen=335 pass=4 image=a0006820 from=xdp_ddos01_blac pid=1 JIT code: : 55 48 89 e5 48 81 ec 28 02 00 00 48 89 9d d8 fd JIT code: 0010: ff ff 4c 89 ad e0 fd ff ff 4c 89 b5 e8 fd ff ff JIT code: 0020: 4c 89 bd f0 fd ff ff 31 c0 48 89 85 f8 fd ff ff JIT code: 0030: bb 02 00 00 00 48 8b 77 08 48 8b 7f 00 48 89 fa JIT code: 0040: 48 83 c2 0e 48 39 f2 0f 87 e1 00 00 00 48 0f b6 JIT code: 0050: 4f 0c 48 0f b6 57 0d 48 c1 e2 08 48 09 ca 48 89 JIT code: 0060: d1 48 81 e1 ff 00 00 00 41 b8 06 00 00 00 49 39 JIT code: 0070: c8 0f 87 b7 00 00 00 48 81 fa 88 a8 00 00 74 0e JIT code: 0080: b9 0e 00 00 00 48 81 fa 81 00 00 00 75 1a 48 89 JIT code: 0090: fa 48 83 c2 12 48 39 f2 0f 87 90 00 00 00 b9 12 JIT code: 00a0: 00 00 00 48 0f b7 57 10 bb 02 00 00 00 48 81 e2 JIT code: 00b0: ff ff 00 00 48 83 fa 08 75 49 48 01 cf 31 db 48 JIT code: 00c0: 89 fa 48 83 c2 14 48 39 f2 77 38 8b 7f 0c 89 7d JIT code: 00d0: fc 48 89 ee 48 83 c6 fc 48 bf 00 9c 24 5f 07 88 JIT code: 00e0: ff ff e8 29 cd 13 e1 bb 02 00 00 00 48 83 f8 00 JIT code: 00f0: 74 11 48 8b 78 00 48 83 c7 01 48 89 78 00 bb 01 JIT code: 0100: 00 00 00 89 5d f8 48 89 ee 48 83 c6 f8 48 bf c0 JIT code: 0110: 76 12 13 04 88 ff ff e8 f4 cc 13 e1 48 83 f8 00 JIT code: 0120: 74 0c 48 8b 78 00 48 83 c7 01 48 89 78 00 48 89 JIT code: 0130: d8 48 8b 9d d8 fd ff ff 4c 8b ad e0 fd ff ff 4c JIT code: 0140: 8b b5 e8 fd ff ff 4c 8b bd f0 fd ff ff c9 c3 $ echo $((0x140)) 320 $ echo $((0x140 + 15)) 335 Using same example code, thus BPF instructions-size was 440 bytes, so the JIT'ed code size does get smaller. ___ iovisor-dev mailing list iovisor-dev@lists.iovisor.org https://lists.iovisor.org/mailman/listinfo/iovisor-dev
Re: [iovisor-dev] Describing howto read the eBPF generated ELF binary
On Mon, 6 Mar 2017 16:14:06 -0800 Alexei Starovoitov via iovisor-dev wrote: > On Mon, Mar 6, 2017 at 10:29 AM, Jesper Dangaard Brouer > wrote: > > On Mon, 6 Mar 2017 09:11:46 -0800 > > Alexei Starovoitov via iovisor-dev wrote: > > > >> On Mon, Mar 6, 2017 at 3:53 AM, Jesper Dangaard Brouer > >> 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 > >> > 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 > >> > > >> > 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 OffSize ES Flg > >> > Lk Inf Al > >> > + [ 0]NULL 00 00 00 > >> > 0 0 0 > >> > + [ 1] .strtabSTRTAB 000320 72 00 > >> > 0 0 1 > >> > + [ 2] .text PROGBITS 40 00 00 AX > >> > 0 0 4 > >> > + [ 3] xdp_prog PROGBITS 40 0001b8 00 AX > >> > 0 0 8 > >> > + [ 4] .relxdp_prog REL 000300 20 10 > >> > 7 3 8 > >> > + [ 5] maps PROGBITS 0001f8 28 00 WA > >> > 0 0 4 > >> > + [ 6] licensePROGBITS 000220 04 00 WA > >> > 0 0 1 > >> > + [ 7] .symtabSYMTAB 000228 d8 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. > it will show section names, asm code and original C code > if compiled with -g
Re: [iovisor-dev] Describing howto read the eBPF generated ELF binary
On Mon, Mar 6, 2017 at 10:29 AM, Jesper Dangaard Brouer wrote: > On Mon, 6 Mar 2017 09:11:46 -0800 > Alexei Starovoitov via iovisor-dev wrote: > >> On Mon, Mar 6, 2017 at 3:53 AM, Jesper Dangaard Brouer >> 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 >> > 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 >> > >> > 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 OffSize ES Flg Lk >> > Inf Al >> > + [ 0]NULL 00 00 00 0 >> > 0 0 >> > + [ 1] .strtabSTRTAB 000320 72 00 0 >> > 0 1 >> > + [ 2] .text PROGBITS 40 00 00 AX 0 >> > 0 4 >> > + [ 3] xdp_prog PROGBITS 40 0001b8 00 AX 0 >> > 0 8 >> > + [ 4] .relxdp_prog REL 000300 20 10 7 >> > 3 8 >> > + [ 5] maps PROGBITS 0001f8 28 00 WA 0 >> > 0 4 >> > + [ 6] licensePROGBITS 000220 04 00 WA 0 >> > 0 1 >> > + [ 7] .symtabSYMTAB 000228 d8 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 iovisor-dev@lists.iovisor.org https://lists.iovisor.o
Re: [iovisor-dev] Describing howto read the eBPF generated ELF binary
On Mon, 6 Mar 2017 09:11:46 -0800 Alexei Starovoitov via iovisor-dev wrote: > On Mon, Mar 6, 2017 at 3:53 AM, Jesper Dangaard Brouer > 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 > > 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 > > > > 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 OffSize ES Flg Lk > > Inf Al > > + [ 0]NULL 00 00 00 0 > > 0 0 > > + [ 1] .strtabSTRTAB 000320 72 00 0 > > 0 1 > > + [ 2] .text PROGBITS 40 00 00 AX 0 > > 0 4 > > + [ 3] xdp_prog PROGBITS 40 0001b8 00 AX 0 > > 0 8 > > + [ 4] .relxdp_prog REL 000300 20 10 7 > > 3 8 > > + [ 5] maps PROGBITS 0001f8 28 00 WA 0 > > 0 4 > > + [ 6] licensePROGBITS 000220 04 00 WA 0 > > 0 1 > > + [ 7] .symtabSYMTAB 000228 d8 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 iovisor-dev@lists.iovisor.org https://lists.iovisor.org/mailman/listinfo/iovisor-dev
Re: [iovisor-dev] Describing howto read the eBPF generated ELF binary
On Mon, Mar 6, 2017 at 3:53 AM, Jesper Dangaard Brouer 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 > 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 > > 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 OffSize ES Flg Lk > Inf Al > + [ 0]NULL 00 00 00 0 > 0 0 > + [ 1] .strtabSTRTAB 000320 72 00 0 > 0 1 > + [ 2] .text PROGBITS 40 00 00 AX 0 > 0 4 > + [ 3] xdp_prog PROGBITS 40 0001b8 00 AX 0 > 0 8 > + [ 4] .relxdp_prog REL 000300 20 10 7 > 3 8 > + [ 5] maps PROGBITS 0001f8 28 00 WA 0 > 0 4 > + [ 6] licensePROGBITS 000220 04 00 WA 0 > 0 1 > + [ 7] .symtabSYMTAB 000228 d8 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 iovisor-dev@lists.iovisor.org https://lists.iovisor.org/mailman/listinfo/iovisor-dev
Re: [iovisor-dev] Describing howto read the eBPF generated ELF binary
On Mon, Mar 6, 2017 at 7:07 AM, Jesper Dangaard Brouer via iovisor-dev wrote: > (repost with subscribed email) > 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 > signatur, to make is as easy as possible for people to correct me). > as far as I know, it's all correct. > And anything else users can use the readelf output for? > maybe also explain the maps section? I think user only need to know the xdp_prog and maps. Regards, William ___ iovisor-dev mailing list iovisor-dev@lists.iovisor.org https://lists.iovisor.org/mailman/listinfo/iovisor-dev
[iovisor-dev] Describing howto read the eBPF generated ELF binary
(repost with subscribed email) 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 signatur, 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 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 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 OffSize ES Flg Lk Inf Al + [ 0]NULL 00 00 00 0 0 0 + [ 1] .strtabSTRTAB 000320 72 00 0 0 1 + [ 2] .text PROGBITS 40 00 00 AX 0 0 4 + [ 3] xdp_prog PROGBITS 40 0001b8 00 AX 0 0 8 + [ 4] .relxdp_prog REL 000300 20 10 7 3 8 + [ 5] maps PROGBITS 0001f8 28 00 WA 0 0 4 + [ 6] licensePROGBITS 000220 04 00 WA 0 0 1 + [ 7] .symtabSYMTAB 000228 d8 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 + -- 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
[iovisor-dev] Describing howto read the eBPF generated ELF binary
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 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 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 OffSize ES Flg Lk Inf Al + [ 0]NULL 00 00 00 0 0 0 + [ 1] .strtabSTRTAB 000320 72 00 0 0 1 + [ 2] .text PROGBITS 40 00 00 AX 0 0 4 + [ 3] xdp_prog PROGBITS 40 0001b8 00 AX 0 0 8 + [ 4] .relxdp_prog REL 000300 20 10 7 3 8 + [ 5] maps PROGBITS 0001f8 28 00 WA 0 0 4 + [ 6] licensePROGBITS 000220 04 00 WA 0 0 1 + [ 7] .symtabSYMTAB 000228 d8 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 + ___ iovisor-dev mailing list iovisor-dev@lists.iovisor.org https://lists.iovisor.org/mailman/listinfo/iovisor-dev
