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

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

On 1/23/23 07:50, Jose E. Marchesi wrote:
> 
>> On 1/5/23 10:30 AM, 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.
>>
>> w.r.t c2x attribute syntax discussion in 01/19 office hour discussion.
>>
>> I have checked clang c2x syntax w.r.t.
>> btf_type_tag and btf_decl_tag. They are both supported
>> with clang 15 and 16.
>>
>> See:
>> https://clang.llvm.org/docs/AttributeReference.html
>>
>> The c2x btf_decl_tag attr syntax is [[clang::btf_decl_tag("")]].
>> The c2x btf_type_tag attr syntax is [[clang::btf_type_tag("")]].
>>
>> $ cat t.c
>> int [[clang::btf_type_tag("aa")]] * [[clang::btf_type_tag("bb")]] *f;
>> [[clang::btf_decl_tag("cc")]] int foo() { return 5; }
>> int bar() { return foo(); }
>> $ clang -std=c2x -g -O2 -c t.c
>> $ llvm-dwarfdump t.o | grep btf | grep tag
>>                   DW_AT_name    ("btf_type_tag")
>>                   DW_AT_name    ("btf_type_tag")
>>                   DW_AT_name    ("btf_decl_tag")
>>
>> I double checked and the c2x syntax above generates the *same*
>> type IR and dwarf compared to __attribute__ style attributes.
>>
>> [...]
> 
> Thanks for checking.
> 
> That matches our impression that C2X type attributes actually order the same
> way than sparse type annotations, at least in the cases we are
> interested on.

I have been experimenting with the C2x syntax in GCC and the results are
similarly promising. It looks like with the C2x syntax, the 'type_tag's
always associate in the same way as sparse.

For GCC the syntax is (or will be)
  [[gnu::btf_decl_tag("foo")]] and
  [[gnu::btf_type_tag("bar")]]
respectively.

I am not sure it is necessary to use the C2x syntax for decl_tag, iirc
there are no issues with the __attribute__ syntax for decl_tag. Either
one should be ok.

With C2x syntax, in the internal representation and in the generated
DWARF, the type_tag attributes are attached to the same elements of
the declaration as sparse attaches them to.

I checked all the examples we looked at and it seems they are
all "fixed" with the C2x syntax, in that GCC agrees with sparse.
For example,

$ cat ex2.c
int __attribute__((btf_type_tag("tag1"))) * __attribute__((btf_type_tag("tag2"))) * g;

We saw that this example was problematic with the __attribute__ syntax
in that GCC associates "tag1" with (int **) while sparse associates
"tag1" with (int).

Using the c2x syntax, "tag1" is associated with (int) and "tag2" with
(int *) the same as in sparse:
$ cat ex2-c2x.c
int [[gnu::btf_type_tag("tag1")]] * [[gnu::btf_type_tag("tag2")]] * g;
$ bpf-unknown-none-gcc --std=c2x -c -gbtf -gdwarf ex2-c2x.c -o ex2-c2x.o
$ bpftool btf dump file ex2-c2x.o
[1] INT 'int' size=4 bits_offset=0 nr_bits=32 encoding=SIGNED
[2] TYPE_TAG 'tag1' type_id=1
[3] PTR '(anon)' type_id=2
[4] TYPE_TAG 'tag2' type_id=3
[5] PTR '(anon)' type_id=4
[6] VAR 'g' type_id=5, linkage=global


I also spent some studying the C2x draft standard [1] to check whether
this ordering is documented by the standard or up to the implementation.
  [1] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3054.pdf
  (I think this is the most recent draft, dated 3 Sep 2022)

I believe the "sparse-like" ordering is in fact required by the
standard, which is great for us.

The relevant section is 6.7: Declarations. Section 6.7.12 covers only
syntax of attributes themselves. The ordering/association rules are
documented by the sections for each component of a declaration. Section
6.7.6 is particularly relevant, 6.7.6.1 discusses pointer declarators
specifically.

From my understanding, the general rule is that an attribute modifies
the element of a declaration immediately to the left of it, which is
the same as the intuitive sparse ordering.

So it seems like using the C2x standard attribute syntax may be a
very nice solution to our problem. But we should keep in mind that C2x
is still a draft so this attribute syntax could potentially change.