Re: Follow up from the btf_type_tag discussion in the BPF office hours

[Yonghong Song <yhs@meta.com>]

On 12/15/22 10:43 AM, Jose E. Marchesi wrote:
> 
> Of the two problems discussed:
> 
> 1. DW_TAG_LLVM_annotation not being able to denote annotations to
>     non-pointed based types.  clang currently ignores these instances.
> 
>     We discussed two possible options to deal with this:
>     1.1 To continue ignoring these cases in the front-end, keep the dwarf
>         expressiveness limitation, and document it.
>     1.2 To change DW_TAG_LLVM_annotation so it behaves like a qualifier
>         DIE (like const, volatile, etc.) so it can apply to any type.

Thanks for the detailed update. Yes, we do want to __tag behaving like
a qualifier.

Today clang only support 'base_type <type_tag> *' style of code.
But we are open to support non-pointer style of tagging like
'base_type <type_tag> global_var'. Because of this, the following
dwarf output should be adopted:
    C: int __tag1 * __tag2 * p;
    dwarf: ptr -> __tag2 --> ptr -> __tag1 -> int
or
    C: int __tag1 g;
    dwarf: var_g -> __tag1 --> int

The above format *might* require particular dwarf tools to add support
for __tag attribute. But I think it is a good thing in the long run
esp. if we might add support to non-pointer types. In current
implementation, dwarf tools can simply ignore the children of ptr
which they may already do it.

> 
> 2. The ordering problem: sparse annotations order differently than
>     GNU/C99 compiler attributes.  Therefore translating 1-to-1 from
>     sparse annotations to compiler attributes results in attributes with
>     different syntax than normal compiler attributes.
> 
>     This was accepted in clang.
>     But found resistance in GCC when we sent the first patch series.
> 
>     During the meeting we went thru several possible ways of dealing with
>     this problem, but we didn't reach any conclusion on what to do, since
>     the time ran out.
> 
> We agreed to continue the discussion at the BPF office hours next 5
> January 2023.
> 
> In the meanwhile, below in this email is a slightly updated version of
> the material used to go thru the topics during the discussion.  If there
> is any mistake or if you see that our understanding of the
> problem/situation is not correct, please point it out.  If you want to
> add more information, please do so by replying to this thread.
> 
> Finally, it was agreed that we (GCC BPF hackers) would send Yonghong our
> github accounts so he can subscribe us to notifications in the llvm
> phabricator, so we can be aware of potentially ABI/breaking changes at
> the time they are discussed, and not afterwards scanning bpf@vger.  I
> alredy sent him the information.
> 
> Thank you for your time today.  It is appreciated.
> 
[...]