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 18:33:14 +0100 [thread overview]
Message-ID: <20200303173314.GA74093@krava> (raw)
In-Reply-To: <CAEf4BzY8_=wcL3N96eS-jcSPBL=ueMgQg+m=Fxiw+o0Tc7F23Q@mail.gmail.com>
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>
thanks,
jirka
next prev parent reply other threads:[~2020-03-03 17:33 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 [this message]
2020-03-03 18:00 ` Andrii Nakryiko
2020-03-03 20:05 ` Jiri Olsa
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=20200303173314.GA74093@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.