From: Ilya Leoshkevich <iii@linux.ibm.com>
To: Daniel Borkmann <daniel@iogearbox.net>
Cc: John Fastabend <john.fastabend@gmail.com>,
Alexei Starovoitov <alexei.starovoitov@gmail.com>,
Alexei Starovoitov <ast@kernel.org>, bpf <bpf@vger.kernel.org>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>
Subject: Re: [RFC PATCH bpf-next] bpf: allow JIT debugging if CONFIG_BPF_JIT_ALWAYS_ON is set
Date: Thu, 7 Nov 2019 16:30:00 +0100 [thread overview]
Message-ID: <335309FE-C7AF-4B89-AC2A-D9138B1E4589@linux.ibm.com> (raw)
In-Reply-To: <2d4334ad-545d-13b6-224a-14420e1da4c0@iogearbox.net>
> Am 07.11.2019 um 00:07 schrieb Daniel Borkmann <daniel@iogearbox.net>:
>
> On 11/6/19 5:50 PM, John Fastabend wrote:
>> Ilya Leoshkevich wrote:
>>>> Am 06.11.2019 um 17:15 schrieb Alexei Starovoitov <alexei.starovoitov@gmail.com>:
>>>> On Wed, Nov 6, 2019 at 8:12 AM Ilya Leoshkevich <iii@linux.ibm.com> wrote:
>>>>>
>>>>> Currently it's not possible to set bpf_jit_enable = 2 when
>>>>> CONFIG_BPF_JIT_ALWAYS_ON is set, which makes debugging certain problems
>>>>> harder.
>>>>
>>>> This is obsolete way of debugging.
>>>> Please use bpftool dump jited instead.
>>>
>>> Is there a way to integrate bpftool nicely with e.g. test_verifier?
>>> With bpf_jit_enable = 2, I can see JITed code for each test right away,
>>> without pausing it (via gdb or rebuilding with added sleep()) and
>>> running bpftool.
>> On the library side we can set the log_level causing the verifier logic
>> steps to be printed. I guess adding it to bpftool might be nice. At least
>> I would find it useful. I'll probably get to it sometime if its not
>> already there somewhere and/or someone doesn't beat me to it.
>
> +1
>
> Was wondering whether it may be worth it moving parts of the logic from bpftool
> into libbpf wrt jit dump as a higher level api, so it could be used directly for
> checking out the jit disasm + opcodes for specific tests given we have the fd
> there as well, but that might be too specific perhaps and would bring one more
> lib dependency to libbpf for a rather narrow use case. Adding sleep before prog
> fd close and/or shelling out to bpftool etc all is a crude temporary hack as
> well (currently using something long these lines locally). Would it make sense
> to dump some meta data and generated opcodes per test case to a file as opt-in
> e.g. ./test_verifier 711 --dump produces 711.opcodes out of bpf_obj_get_info_by_fd()
> which then bpftool could dump this artifact through its own disasm?
>
> Thanks,
> Daniel
Yes, this sounds fine - if the test fails or behaves strangely, I won't
have to re-run it using a special setup, but rather just disasm the
dumped JITted image (maybe even without bpftool, just with objdump).
Another question though: what about seccomp? It looks as if those
programs are not shown by bpftool, since they are not created using bpf
syscall.
Best regards,
Ilya
next prev parent reply other threads:[~2019-11-07 15:30 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-06 16:12 [RFC PATCH bpf-next] bpf: allow JIT debugging if CONFIG_BPF_JIT_ALWAYS_ON is set Ilya Leoshkevich
2019-11-06 16:15 ` Alexei Starovoitov
2019-11-06 16:28 ` Ilya Leoshkevich
2019-11-06 16:50 ` John Fastabend
2019-11-06 23:07 ` Daniel Borkmann
2019-11-07 15:30 ` Ilya Leoshkevich [this message]
2019-11-07 16:19 ` Daniel Borkmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=335309FE-C7AF-4B89-AC2A-D9138B1E4589@linux.ibm.com \
--to=iii@linux.ibm.com \
--cc=alexei.starovoitov@gmail.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=gor@linux.ibm.com \
--cc=heiko.carstens@de.ibm.com \
--cc=john.fastabend@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).