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

[Eduard Zingerman via Phabricator via cfe-commits]

eddyz87 added a comment.

In D143967#4232089 <https://reviews.llvm.org/D143967#4232089>, @jemarch wrote:

> 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.

I'm not sure I understand, the DWARF #2 is not a valid representation of the program for all the reasons you write.
Current LLVM implementation should generate DWARF #1 in this case.
If some tooling applies such tags movement it should also apply appropriate copying of tags, e.g. it should transform DWARF like this:

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

(and it is what needs to be implemented in pahole to get BTF qualifiers ordering expected by kernel, but the move is in the opposite direction).

> 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.

Need to read a bit about Rust, can't comment right now.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D143967/new/

https://reviews.llvm.org/D143967