From: Eduard Zingerman <eddyz87@gmail.com>
To: David Faust <david.faust@oracle.com>,
"Jose E. Marchesi" <jose.marchesi@oracle.com>,
bpf@vger.kernel.org
Cc: James Hilliard <james.hilliard1@gmail.com>,
Nick Desaulniers <ndesaulniers@google.com>,
David Malcolm <dmalcolm@redhat.com>,
Julia Lawall <julia.lawall@inria.fr>,
elena.zannoni@oracle.com, acme@redhat.com,
Yonghong Song <yhs@fb.com>, Mykola Lysenko <mykolal@fb.com>
Subject: Re: BTF tag support in DWARF (notes for today's BPF Office Hours)
Date: Wed, 22 Feb 2023 00:57:32 +0200 [thread overview]
Message-ID: <1b84d1477c3648e6d20bacaf1447724fb78e282f.camel@gmail.com> (raw)
In-Reply-To: <1fe666d0-aab1-5b6f-8264-57ff282b5e52@oracle.com>
On Tue, 2023-02-21 at 11:38 -0800, David Faust wrote:
[...]
> Very nice.
> Keeping the 0x6000 tag and instead changing the name sounds good to us.
>
> From the GCC side, support for BTF tags will be new either way but
> conserving DWARF tag numbers is a good idea.
Great, thank you!
> > Both [1] and [2] are in a workable state, but [2] lacks support for
> > subroutine types and "void *" for now. If you are onboard with this change
> > I'll proceed with finalizing [1] and [2]. (Also, ":v2" suffix might be not
> > the best, I'm open to naming suggestions).
>
> As for the name, I am not sure the ":v2" suffix is a good idea.
>
> If we need a new name anyway, this could be a good opportunity to use
> something more generic. The annotation DIEs, especially with the new
> format, could be more widely useful than exclusively for producing BTF.
>
> For example, some other tool may want to process these same user
> annotations which are now recorded in DWARF, but may not involve BPF/BTF
> at all. Tying "btf" into the name seems to unnecessarily discourage
> those use cases.
>
> What do you think about something like "debug_type_tag" or
> "debug_type_annotation" (and a similar update for the decl tags)?
> The translation into BTF records would be the same, but the DWARF info
> would stand on its own without being tied to BTF.
>
> (Naming is a bit tricky since terms like 'tag' are already in use by
> DWARF, e.g. "type tag" in the context of DWARF DIEs makes me think of
> DW_TAG_xxxx_type...)
>
> As far as I understand, early proposals for the tags were more generic
> but the LLVM reviewers wished for something more specific due to the
> relatively limited use of the tags at the time. Now that the tags and
> their DWARF format have matured I think a good case can be made to
> make these generic. We'd be happy to help push for such change.
On the other hand, BTF is a thing we are using this annotation for.
Any other tool can reuse DW_TAG_LLVM_annotation, but it will need a
way to distinguish it's annotations from BTF annotations. And this can
be done by using a different DW_AT_name. So, it seems logical to
retain "btf" in the DW_AT_name. What do you think?
> > As a somewhat orthogonal question, would it be possible for you to use the
> > same 0x6000 tag on GCC side? I looked at master branch of [3] but can't
> > find any mentions of btf_type_tag.
>
> Yes, we plan to use the same 0x6000 in GCC. Support for btf_type_tag isn't
> committed in master yet; I originally worked on patches [1] last spring but
> they were not committed due to some of the issues we've now worked out
> (notably the attribute ordering/association problem). But 0x6000 is not
> currently in use in GCC and didn't come up as a problem for those patches,
> so I don't think it should be an issue.
Understood, thank you for the clarification.
Thanks,
Eduard
next prev parent reply other threads:[~2023-02-21 22:57 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-05 11:37 BTF tag support in DWARF (notes for today's BPF Office Hours) Jose E. Marchesi
2023-01-05 18:30 ` Jose E. Marchesi
2023-01-22 17:53 ` Yonghong Song
2023-01-23 15:50 ` Jose E. Marchesi
2023-01-23 18:43 ` David Faust
2023-01-24 7:37 ` Yonghong Song
2023-02-20 23:42 ` Eduard Zingerman
2023-02-21 19:38 ` David Faust
2023-02-21 22:57 ` Eduard Zingerman [this message]
2023-02-22 18:03 ` David Faust
2023-02-22 18:11 ` Alexei Starovoitov
2023-02-22 19:43 ` Eduard Zingerman
2023-02-27 21:13 ` Andrii Nakryiko
2023-02-28 0:41 ` Eduard Zingerman
2023-02-28 0:45 ` Andrii Nakryiko
2023-02-28 0:57 ` Eduard Zingerman
2023-02-28 2:44 ` Alexei Starovoitov
2023-02-28 5:28 ` Andrii Nakryiko
2023-02-28 6:53 ` Alexei Starovoitov
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=1b84d1477c3648e6d20bacaf1447724fb78e282f.camel@gmail.com \
--to=eddyz87@gmail.com \
--cc=acme@redhat.com \
--cc=bpf@vger.kernel.org \
--cc=david.faust@oracle.com \
--cc=dmalcolm@redhat.com \
--cc=elena.zannoni@oracle.com \
--cc=james.hilliard1@gmail.com \
--cc=jose.marchesi@oracle.com \
--cc=julia.lawall@inria.fr \
--cc=mykolal@fb.com \
--cc=ndesaulniers@google.com \
--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