[PATCH] D143967: [DebugInfo][BPF] Add 'btf:type_tag' annotation in DWARF

[Jose E. Marchesi via cfe-commits]

> eddyz87 added a subscriber: anakryiko.
> eddyz87 added a comment.
>
> In D143967#4231746 <https://reviews.llvm.org/D143967#4231746>, @jemarch wrote:
>
>>> eddyz87 added a comment.
>>> ...
>>> If we consider type tag a qualifier, conceptually it would be simpler
>>> if ordering would not matter for it as well, so that the following
>>> have identical meaning:
>>>
>>> - `__tag volatile int`
>>> - `volatile __tag int`
>>
>> Makes sense.
>>
>> But then I think we should allow the tags to be anywhere in the chain in
>> the DWARF, and not necessarily in the qualified type.  For example
>> given:
>>
>>   typedef const int bar;
>>   volatile bar __tag1 foo;
>>
>> The resulting DWARF type chain is:
>>
>>   volatile -> typedef (bar) -> const -> int
>>
>> IMO we should allow __tag1 to be a child of any of the elements of the
>> chain, like:
>>
>>   volatile -> typedef (bar) -> const -> int
>>                    |
>>                  __tag1
>>
>> or
>>
>>   volatile -> typedef (bar) -> const -> int
>>                                          |
>>                                       __tag1
>>
>> or
>>
>>   volatile -> typedef (bar) -> const -> int
>>                                  |
>>                               __tag1
>>
>> or
>>
>>   volatile -> typedef (bar) -> const -> int
>>      |
>>    __tag1
>>
>> would be all accepted and equivalent.  Also Faust noted that GCC
>> sometimes optimizes out the typedef nodes, so we need to be able to
>> place the tags (in the internal representatinos) in the typedef'ed type
>> instead.
>
> Well, it's a logical consequence, I guess.
> In practice I'm going to emit it like below:
>
>   volatile -> const -> int
>                         |
>                      __tag1
>
> But please remember that in BTF it would have to be encoded like this:
>
>   __tag1 -> volatile -> const -> int
>
> (that's how kernel expects it, we can change the kernel but will loose
> backwards compatibility).

Thinking about typedef, some C cases may be problematic if we adopt the
flexible rule we are discussing:

  typedef int bar;
  const bar __tag1 var1;
  bar var2;

  DWARF:

  var1 -> const -> typedef (bar) -> int
           |           ^
          __tag1       |
                       |
  var2 ----------------+

If we would allow __tag1 to be "moved" to either the typedef DWARF node
or the node for int like this:

  DWARF:

  var1 -> const -> typedef (bar) -> int
                       ^             |
                       |          __tag1
  var2 ----------------+

Then the __tag1 would also apply to var2's type.  But I would say in the
C snippet above __tag1 should apply to the type of var1, but not
to the type of var2.

This makes me think we shouldn't allow tags to "jump" over typedef
nodes, in neither DWARF nor BTF.

PS: I am a bit concerned with the fact that the kernel's interpretation
    of BTF is so rigit in this case as to assume C's type system
    semantics when it comes to type qualifiers.  Other languages may be
    coming to the BPF world (Rust, for example) and in these languages
    the ordering of type qualifiers may actually matter.  There is a
    reason why DWARF encodes qualifiers as explicit nodes in the type
    chain rather than as attributes of the type nodes.