From: Sandipan Das <sandipan@linux.vnet.ibm.com>
To: Daniel Borkmann <daniel@iogearbox.net>,
Jakub Kicinski <jakub.kicinski@netronome.com>
Cc: ast@kernel.org, netdev@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, mpe@ellerman.id.au,
naveen.n.rao@linux.vnet.ibm.com,
Quentin Monnet <quentin.monnet@netronome.com>
Subject: Re: [PATCH bpf-next v3 10/10] tools: bpftool: add delimiters to multi-function JITed dumps
Date: Wed, 23 May 2018 16:07:40 +0530 [thread overview]
Message-ID: <7142939b-515e-50ac-bc0b-50444bf9cc97@linux.vnet.ibm.com> (raw)
In-Reply-To: <2dabfa7f-15b8-236c-7724-33bc3da7e549@iogearbox.net>
On 05/23/2018 02:38 PM, Daniel Borkmann wrote:
> On 05/22/2018 09:55 PM, Jakub Kicinski wrote:
>> On Tue, 22 May 2018 22:46:13 +0530, Sandipan Das wrote:
>>> + if (info.nr_jited_func_lens && info.jited_func_lens) {
>>> + struct kernel_sym *sym = NULL;
>>> + unsigned char *img = buf;
>>> + __u64 *ksyms = NULL;
>>> + __u32 *lens;
>>> + __u32 i;
>>> +
>>> + if (info.nr_jited_ksyms) {
>>> + kernel_syms_load(&dd);
>>> + ksyms = (__u64 *) info.jited_ksyms;
>>> + }
>>> +
>>> + lens = (__u32 *) info.jited_func_lens;
>>> + for (i = 0; i < info.nr_jited_func_lens; i++) {
>>> + if (ksyms) {
>>> + sym = kernel_syms_search(&dd, ksyms[i]);
>>> + if (sym)
>>> + printf("%s:\n", sym->name);
>>> + else
>>> + printf("%016llx:\n", ksyms[i]);
>>> + }
>>> +
>>> + disasm_print_insn(img, lens[i], opcodes, name);
>>> + img += lens[i];
>>> + printf("\n");
>>> + }
>>> + } else {
>>
>> The output doesn't seem to be JSON-compatible :( We try to make sure
>> all bpftool command can produce valid JSON when run with -j (or -p)
>> switch.
>>
>> Would it be possible to make each function a separate JSON object with
>> "name" and "insn" array? Would that work?
>
> Sandipan, could you take a look at this? Given there's json output today we
> should definitely try not to break it; presumably this would be one final
> respin of your series with this fixed.
>
>
Sure. With a few changes, I am able get JSON output like the following:
# echo 0 > /proc/sys/net/core/bpf_jit_kallsyms
# bpftool prog -p dump jited id 1
[{
"name": "0xd00000000aa80000",
"insns": [{
"pc": "0x0",
"operation": "nop",
"operands": [null
]
},{
"pc": "0x4",
"operation": "nop",
"operands": [null
]
},{
"pc": "0x8",
"operation": "mflr",
"operands": ["r0"
]
},{
"pc": "0xc",
"operation": "std",
"operands": ["r0","16","(","r1",")"
]
},{
"pc": "0x10",
"operation": "stdu",
"operands": ["r1","-112","(","r1",")"
]
},{
...
}
]
},{
"name": "0xd00000000aae0000",
"insns": [{
"pc": "0x0",
"operation": "nop",
"operands": [null
]
},{
"pc": "0x4",
"operation": "nop",
"operands": [null
]
},{
"pc": "0x8",
"operation": "mflr",
"operands": ["r0"
]
},{
...
}
]
}
]
# echo 1 > /proc/sys/net/core/bpf_jit_kallsyms
# bpftool prog -p dump jited id 1
[{
"name": "bpf_prog_b811aab41a39ad3d_foo",
"insns": [{
"pc": "0x0",
"operation": "nop",
"operands": [null
]
},{
"pc": "0x4",
"operation": "nop",
"operands": [null
]
},{
"pc": "0x8",
"operation": "mflr",
"operands": ["r0"
]
},{
"pc": "0xc",
"operation": "std",
"operands": ["r0","16","(","r1",")"
]
},{
"pc": "0x10",
"operation": "stdu",
"operands": ["r1","-112","(","r1",")"
]
},{
...
}
]
},{
"name": "bpf_prog_196af774a3477707_F",
"insns": [{
"pc": "0x0",
"operation": "nop",
"operands": [null
]
},{
"pc": "0x4",
"operation": "nop",
"operands": [null
]
},{
"pc": "0x8",
"operation": "mflr",
"operands": ["r0"
]
},{
...
}
]
}
]
If this is okay, I can send out the next revision with these changes.
Other than that, for powerpc64, there is a problem with the way the
binutils disassembler code (in "opcodes/ppc-dis.c") passes arguments
to the callback fprintf_json().
In fprintf_json(), we always expect the va_list elements to resolve
to strings (char *). But for powerpc64, the register or immediate
operands are always passed as integers. So, when the code attempts
to resolve these operands using va_arg(ap, char *), bpftool crashes.
For now, I am using a workaround based on vsnprintf() but this does
not get the semantics correct for memory operands. You can probably
see that for the store instructions in the JSON dump above this.
Daniel,
Would it be okay if I send out a fix for this in a different series?
- Sandipan
next prev parent reply other threads:[~2018-05-23 10:37 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-22 17:16 [PATCH bpf-next v3 00/10] bpf: enhancements for multi-function programs Sandipan Das
2018-05-22 17:16 ` [PATCH bpf-next v3 01/10] bpf: support 64-bit offsets for bpf function calls Sandipan Das
2018-05-22 17:16 ` [PATCH bpf-next v3 02/10] bpf: powerpc64: pad function address loads with NOPs Sandipan Das
2018-05-22 17:16 ` [PATCH bpf-next v3 03/10] bpf: powerpc64: add JIT support for multi-function programs Sandipan Das
2018-05-22 17:16 ` [PATCH bpf-next v3 04/10] bpf: get kernel symbol addresses via syscall Sandipan Das
2018-05-22 17:16 ` [PATCH bpf-next v3 05/10] tools: bpf: sync bpf uapi header Sandipan Das
2018-05-22 17:16 ` [PATCH bpf-next v3 06/10] tools: bpftool: resolve calls without using imm field Sandipan Das
2018-05-22 19:36 ` Jakub Kicinski
2018-05-22 17:16 ` [PATCH bpf-next v3 07/10] bpf: fix multi-function JITed dump obtained via syscall Sandipan Das
2018-05-22 19:47 ` Jakub Kicinski
2018-05-22 17:16 ` [PATCH bpf-next v3 08/10] bpf: get JITed image lengths of functions " Sandipan Das
2018-05-22 17:16 ` [PATCH bpf-next v3 09/10] tools: bpf: sync bpf uapi header Sandipan Das
2018-05-22 17:16 ` [PATCH bpf-next v3 10/10] tools: bpftool: add delimiters to multi-function JITed dumps Sandipan Das
2018-05-22 19:55 ` Jakub Kicinski
2018-05-23 9:08 ` Daniel Borkmann
2018-05-23 10:37 ` Sandipan Das [this message]
2018-05-23 13:50 ` Daniel Borkmann
2018-05-23 13:59 ` Sandipan Das
2018-05-23 21:32 ` Jakub Kicinski
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=7142939b-515e-50ac-bc0b-50444bf9cc97@linux.vnet.ibm.com \
--to=sandipan@linux.vnet.ibm.com \
--cc=ast@kernel.org \
--cc=daniel@iogearbox.net \
--cc=jakub.kicinski@netronome.com \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=naveen.n.rao@linux.vnet.ibm.com \
--cc=netdev@vger.kernel.org \
--cc=quentin.monnet@netronome.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).