public inbox for bpf@vger.kernel.org
 help / color / mirror / Atom feed
From: Yonghong Song <yhs@meta.com>
To: David Faust <david.faust@oracle.com>,
	"Jose E. Marchesi" <jose.marchesi@oracle.com>
Cc: bpf@vger.kernel.org, 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
Subject: Re: BTF tag support in DWARF (notes for today's BPF Office Hours)
Date: Mon, 23 Jan 2023 23:37:16 -0800	[thread overview]
Message-ID: <caefb2e1-bfb1-58fd-b184-ba2afc940127@meta.com> (raw)
In-Reply-To: <4281ccc7-99db-69df-6675-5c8b5509abc3@oracle.com>



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.

  reply	other threads:[~2023-01-24  7:37 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 [this message]
2023-02-20 23:42   ` Eduard Zingerman
2023-02-21 19:38     ` David Faust
2023-02-21 22:57       ` Eduard Zingerman
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=caefb2e1-bfb1-58fd-b184-ba2afc940127@meta.com \
    --to=yhs@meta.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=ndesaulniers@google.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