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>,
	Networking <netdev@vger.kernel.org>, bpf <bpf@vger.kernel.org>,
	Andrii Nakryiko <andriin@fb.com>, Yonghong Song <yhs@fb.com>,
	Martin KaFai Lau <kafai@fb.com>, Daniel Xu <dxu@dxuuu.xyz>
Subject: Re: [RFC] libbpf: Allow to emit all dependent definitions
Date: Tue, 15 Oct 2019 22:44:07 +0200	[thread overview]
Message-ID: <20191015204407.GA16674@krava> (raw)
In-Reply-To: <CAEf4BzYdJ-hPHVehZriS_synLWtgad9wx_eoN6-JDBUUHFjfgQ@mail.gmail.com>

On Tue, Oct 15, 2019 at 09:22:35AM -0700, Andrii Nakryiko wrote:
> On Tue, Oct 15, 2019 at 6:03 AM Jiri Olsa <jolsa@kernel.org> wrote:
> >
> > Currently the bpf dumper does not emit definitions
> > of pointers to structs. It only emits forward type
> > declarations.
> >
> > Having 2 structs like:
> >
> >    struct B {
> >      int b;
> >    };
> >
> >    struct A {
> >      struct B *ptr;
> >    };
> >
> > the call to btf_dump__dump_type(id = struct A) dumps:
> >
> >    struct B;
> >    struct A {
> >      struct B *ptr;
> >    };
> >
> > It'd ease up bpftrace code if we could dump definitions
> > of all dependent types, like:
> >
> >    struct B {
> >      int b;
> >    };
> >    struct A {
> >      struct B *ptr;
> >    };
> >
> > So we could dereference all the pointers easily, instead
> > of searching for each access member's type and dumping it
> > separately.
> >
> > Adding struct btf_dump_opts::emit_all to do that.
> >
> 
> Hey Jiri,
> 
> Yeah, Daniel Xu mentioned that this would be useful. I haven't thought
> this through very well yet, but I suspect that this simple change
> might not be enough to make this work. There are cases where you are
> not yet allowed to emit definition and have to emit
> forward-declaration first. I suggest trying to use this on vmlinux BTF
> and see if resulting header files still compiles with both Clang and
> GCC. Do you mind checking?

agh right, my test fails for vmlinux BTF

> 
> But also, as we learned over last few months, just adding extra field
> to an opts struct is not backwards-compatible, so we'll need to add
> new API and follow the pattern that we used for
> bpf_object__open_{file,mem).

will check, thanks
jirka

      reply	other threads:[~2019-10-15 20:44 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-15 13:01 [RFC] libbpf: Allow to emit all dependent definitions Jiri Olsa
2019-10-15 16:22 ` Andrii Nakryiko
2019-10-15 20:44   ` 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=20191015204407.GA16674@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=dxu@dxuuu.xyz \
    --cc=jolsa@kernel.org \
    --cc=kafai@fb.com \
    --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.