2021-04-21 15:10 UTC+0200 ~ Christophe Leroy [off-list ref]

Le 20/04/2021 à 05:28, Alexei Starovoitov a écrit :

quoted

On Sat, Apr 17, 2021 at 1:16 AM Christophe Leroy
[off-list ref] wrote:

quoted

Le 16/04/2021 à 01:49, Alexei Starovoitov a écrit :

quoted

On Thu, Apr 15, 2021 at 8:41 AM Quentin Monnet
[off-list ref] wrote:

quoted

2021-04-15 16:37 UTC+0200 ~ Daniel Borkmann [off-list ref]

quoted

On 4/15/21 11:32 AM, Jianlin Lv wrote:

quoted

For debugging JITs, dumping the JITed image to kernel log is
discouraged,
"bpftool prog dump jited" is much better way to examine JITed dumps.
This patch get rid of the code related to bpf_jit_enable=2 mode and
update the proc handler of bpf_jit_enable, also added auxiliary
information to explain how to use bpf_jit_disasm tool after this
change.

Signed-off-by: Jianlin Lv <redacted>

Hello,

For what it's worth, I have already seen people dump the JIT image in
kernel logs in Qemu VMs running with just a busybox, not for kernel
development, but in a context where buiding/using bpftool was not
possible.

If building/using bpftool is not possible then majority of selftests
won't
be exercised. I don't think such environment is suitable for any kind
of bpf development. Much so for JIT debugging.
While bpf_jit_enable=2 is nothing but the debugging tool for JIT
developers.
I'd rather nuke that code instead of carrying it from kernel to kernel.

When I implemented JIT for PPC32, it was extremely helpfull.

As far as I understand, for the time being bpftool is not usable in
my environment because it
doesn't support cross compilation when the target's endianess differs
from the building host
endianess, see discussion at
https://lore.kernel.org/bpf/21e66a09-514f-f426-b9e2-13baab0b938b@csgroup.eu/ (local)


That's right that selftests can't be exercised because they don't build.

The question might be candid as I didn't investigate much about the
replacement of "bpf_jit_enable=2
debugging mode" by bpftool, how do we use bpftool exactly for that ?
Especially when using the BPF
test module ?

the kernel developers can add any amount of printk and dumps to debug
their code,
but such debugging aid should not be part of the production kernel.
That sysctl was two things at once: debugging tool for kernel devs and
introspection for users.
bpftool jit dump solves the 2nd part. It provides JIT introspection to
users.
Debugging of the kernel can be done with any amount of auxiliary code
including calling print_hex_dump() during jiting.

I get the following message when trying the command suggested in the
patch message:

root@vgoip:~# ./bpftool prog dump jited
Error: No libbfd support

Christophe

Hi Christophe,

Bpftool relies on libbfd to disassemble the JIT-ed instructions, but
this is an optional dependency and your version of bpftool has been
compiled without it.

You could try to install it on your system (it is usually shipped with
binutils, package "binutils-dev" on Ubuntu for example). If you want to
cross-compile bpftool, the libbfd version provided by your distribution
may not include support for the target architecture. In that case you
would have to build libbfd yourself to make sure it supports it.

Then you can clean up the results from the libbfd probing:

    $ make -C tools/build/feature/ clean

and recompile bpftool.

I hope this helps,
Quentin