Re: BTF tag support in DWARF (notes for today's BPF Office Hours)

[David Faust <david.faust@oracle.com>]

On 2/20/23 15:42, Eduard Zingerman wrote:
> On Thu, 2023-01-05 at 19:30 +0100, Jose E. Marchesi wrote:
>> We agreed in the meeting to implement Solution 2 below in both GCC and
>> clang.
>>
>> The DW_TAG_LLVM_annotation DIE number will be changed in order to make
>> it possible for pahole to handle the current tags.  The number of the
>> new tag will be shared by both GCC and clang.
>>
>> Thanks everyone for the feedback.
>>
> [...]
> 
> Hi Jose, David,

Hi Eduard,

> 
> Recently I've been working on implementation of the agreed btf_type_tag
> encoding scheme for clang [1] and pahole [2]. While working on this, I came
> to a conclusion that instead of introducing new DWARF tag (0x6001) we can
> reuse the same tag (0x6000), but have a different DW_AT_name field:
> "btf_type_tag:v2" instead of "btf_type_tag".
> 
> For example, the following C code:
> 
>     struct st {
>       int __attribute__((btf_type_tag("a"))) a;
>     } g;
> 
> Produces the following DWARF when [1] is used:
> 
> 0x00000029:   DW_TAG_structure_type
>                 DW_AT_name      ("st")
>                 ...
> 
> 0x0000002e:     DW_TAG_member
>                   DW_AT_name    ("a")
>                   DW_AT_type    (0x00000038 "int")
>                 ...
> 
> 0x00000038:   DW_TAG_base_type
>                 DW_AT_name      ("int")
>                 ...
> 
> 0x0000003c:     DW_TAG_LLVM_annotation
>                   DW_AT_name    ("btf_type_tag:v2")
>                   DW_AT_const_value     ("a")
> 
> I think that this is a tad better than abandoning 0x6000 tag because of
> two reasons:
> - tag numbers are a limited resource;
> - might simplify discussion with upstream.
> 
> (It also makes some implementation details a bit simpler, but this is not
>  very significant).
> 
> What do you think?

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.

> 
> 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.

> 
> 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.

I plan to submit a new set of patches soon, I will add you in CC in case
this or similar issues come up in the discussion.

Thanks
David

[1] https://gcc.gnu.org/pipermail/gcc-patches/2022-May/593936.html

> 
> Thanks,
> Eduard
> 
> [1] https://reviews.llvm.org/D143967
> [2] https://github.com/eddyz87/dwarves/tree/btf-type-tag-v2
> [3] git://gcc.gnu.org/git/gcc.git