From: Jiri Olsa <jolsa@redhat.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>, Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andriin@fb.com>,
Networking <netdev@vger.kernel.org>, bpf <bpf@vger.kernel.org>,
Yonghong Song <yhs@fb.com>, Martin KaFai Lau <kafai@fb.com>,
Jakub Kicinski <kuba@kernel.org>, David Miller <davem@redhat.com>,
John Fastabend <john.fastabend@gmail.com>,
Jesper Dangaard Brouer <hawk@kernel.org>
Subject: Re: [RFC] libbpf,selftests: Question on btf_dump__emit_type_decl for BTF_KIND_FUNC
Date: Tue, 3 Mar 2020 21:05:13 +0100 [thread overview]
Message-ID: <20200303200513.GB74093@krava> (raw)
In-Reply-To: <CAEf4BzYQYJJwLUNhDoKcdgKsMijf9R5vG-vbOBYA-nUAgNs1qA@mail.gmail.com>
On Tue, Mar 03, 2020 at 10:00:02AM -0800, Andrii Nakryiko wrote:
> On Tue, Mar 3, 2020 at 9:33 AM Jiri Olsa <jolsa@redhat.com> wrote:
> >
> > On Tue, Mar 03, 2020 at 09:09:38AM -0800, Andrii Nakryiko wrote:
> > > On Tue, Mar 3, 2020 at 6:12 AM Jiri Olsa <jolsa@kernel.org> wrote:
> > > >
> > > > hi,
> > > > for bpftrace I'd like to print BTF functions (BTF_KIND_FUNC)
> > > > declarations together with their names.
> > > >
> > > > I saw we have btf_dump__emit_type_decl and added BTF_KIND_FUNC,
> > > > where it seemed to be missing, so it prints out something now
> > > > (not sure it's the right fix though).
> > > >
> > > > Anyway, would you be ok with adding some flag/bool to struct
> > > > btf_dump_emit_type_decl_opts, so I could get output like:
> > > >
> > > > kfunc:ksys_readahead(int fd, long long int offset, long unsigned int count) = ssize_t
> > > > kfunc:ksys_read(unsigned int fd, char buf, long unsigned int count) = size_t
> > > >
> > > > ... to be able to the arguments and return type separated,
> > > > so I could easily get to something like above?
> > > >
> > > > Current interface is just vfprintf callback and I'm not sure
> > > > I can rely that it will allywas be called with same arguments,
> > > > like having separated calls for parsed atoms like 'return type',
> > > > '(', ')', '(', 'arg type', 'arg name', ...
> > > >
> > > > I'm open to any suggestion ;-)
> > >
> > > Hey Jiri!
> > >
> > > Can you please elaborate on the use case and problem you are trying to solve?
> > >
> > > I think we can (and probably even should) add such option and support
> > > to dump functions, but whatever we do it should be a valid C syntax
> > > and should be compilable.
> > > Example above:
> > >
> > > kfunc:ksys_read(unsigned int fd, char buf, long unsigned int count) = size_t
> > >
> > > Is this really the syntax you need to get? I think btf_dump, when
> > > (optionally) emitting function declaration, will have to emit that
> > > particular one as:
> > >
> > > size_t ksys_read(unsigned int fd, char buf, long unsigned int count);
> > >
> > > But I'd like to hear the use case before we add this. Thanks!
> >
> > the use case is just for the 'bpftrace -l' output, which displays
> > the probe names that could be used.. for kernel BTF kernel functions
> > it's 'kfunc:function(args)'
> >
> > software:task-clock:
> > hardware:backend-stalls:
> > hardware:branch-instructions:
> > ...
> > tracepoint:kvmmmu:kvm_mmu_pagetable_walk
> > tracepoint:kvmmmu:kvm_mmu_paging_element
> > ...
> > kprobe:console_on_rootfs
> > kprobe:trace_initcall_start_cb
> > kprobe:run_init_process
> > kprobe:try_to_run_init_process
> > ...
> > kfunc:x86_reserve_hardware
> > kfunc:hw_perf_lbr_event_destroy
> > kfunc:x86_perf_event_update
> >
> > I dont want to print the return type as is in C, because it would
> > mess up the whole output, hence the '= <return type>'
> >
> > kfunc:ksys_readahead(int fd, long long int offset, long unsigned int count) = ssize_t
> > kfunc:ksys_read(unsigned int fd, char buf, long unsigned int count) = size_t
> >
> > also possible only in verbose mode ;-)
> >
> > the final shape of the format will be decided in a bpftrace review,
> > but in any case I think I'll need some way to get these bits:
> > <args> <return type>
> >
>
> Ok, I think for your use case it's better for you to implement it
> customly, I don't think this fits btf_dump() C output as is. But you
> have all the right high-level APIs anyways. There is nothing irregular
> about function declarations, thankfully. Pointers to functions are way
> more involved, syntactically, which is already abstracted from you in
> btf_dump__emit_type_decl(). Here's the code:
>
> static int dump_funcs(const struct btf *btf, struct btf_dump *d)
> {
> int err = 0, i, j, cnt = btf__get_nr_types(btf);
> const struct btf_type *t;
> const struct btf_param *p;
> const char *name;
>
> for (i = 1; i <= cnt; i++) {
> t = btf__type_by_id(btf, i);
> if (!btf_is_func(t))
> continue;
>
> name = btf__name_by_offset(btf, t->name_off);
> t = btf__type_by_id(btf, t->type);
> if (!btf_is_func_proto(t))
> return -EINVAL;
>
> printf("kfunc:%s(", name);
> for (j = 0, p = btf_params(t); j < btf_vlen(t); j++, p++) {
> err = btf_dump__emit_type_decl(d, p->type, NULL);
> if (err)
> return err;
> }
> printf(") = ");
>
> err = btf_dump__emit_type_decl(d, t->type, NULL);
> if (err)
> return err;
aaah right, we could move it one level down ;-) ok, that will do
>
> printf(";\n");
> }
> return 0;
> }
>
> Beware, this will crash right now due to NULL field_name, but I'm
> fixing that with a tiny patch in just a second.
>
> Also beware, there are no argument names captures for func_protos...
>
> So with the above (and btf_dump__emit_type_decl() fix for NULL
> field_name), this will produce output:
>
> kfunc:num_digits(int) = int;
> kfunc:copy_from_user_nmi(void *const void *long unsigned int) = long
> unsigned int;
> kfunc:arch_wb_cache_pmem(void *size_t) = void;
> kfunc:__clear_user(void *long unsigned int) = long unsigned int;
thanks, I'll use that
jirka
prev parent reply other threads:[~2020-03-03 20:05 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-03 14:08 [RFC] libbpf,selftests: Question on btf_dump__emit_type_decl for BTF_KIND_FUNC Jiri Olsa
2020-03-03 17:09 ` Andrii Nakryiko
2020-03-03 17:33 ` Jiri Olsa
2020-03-03 18:00 ` Andrii Nakryiko
2020-03-03 20:05 ` Jiri Olsa [this message]
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=20200303200513.GB74093@krava \
--to=jolsa@redhat.com \
--cc=andrii.nakryiko@gmail.com \
--cc=andriin@fb.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@redhat.com \
--cc=hawk@kernel.org \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kafai@fb.com \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=yhs@fb.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).