On 1/23/23 10:43 AM, David Faust wrote:
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.
Thanks for confirmation.
For GCC the syntax is (or will be)
[[gnu::btf_decl_tag("foo")]] and
[[gnu::btf_type_tag("bar")]]
respectively.
Clang could add support for [[gnu::btf_decl_tag("foo")]] as well
once the syntax is agreed by the community and upstreamed.
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.
The same for me. Either is okay.
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.
