All of lore.kernel.org
 help / color / mirror / Atom feed
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


  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.