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

[Yonghong Song <yhs@meta.com>]

On 12/19/22 9:27 AM, Jose E. Marchesi wrote:
> 
> Hi Yonghong.
> 
>> 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.
> 
> I wonder, since these annotations are atomic, is there a reason for not
> using an attribute instead of a DIE tag?  Something like DW_AT_annotation.

Yes, we can. My suggestion is to facilitate gcc implementation. 
Currently clang uses an attribute instead of a DIE tag. I am totally 
fine if gcc uses the same dwarf representation mechanism as clang.

> 
> The attribute could then be used by any DIE (declaration, type, ...) and
> existing DWARF consumers that don't support the new attribute would
> happily just ignore it.

clang already use attributes to represent btf_type_tag and btf_decl_tag.
One of early considerations to use attribute in clang indeed is to avoid 
existing tool changes as much as possible.