> 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.
Yes that was my point: tags can cross qualifiers and still keep C
language semantics, but not (all) typedefs.
> 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).
So the kernel expects tags to precede typedefs as well as qualifiers?
i.e. given this DWARF:
var1 -> const -> typedef (bar) -> int
^ |
| __tag1
|
var2 ----------------+
We have to transform to these two BTF type chains:
var1 -> __tag1 -> const -> typedef (bar) -> int
^
|
var2 -> __tag1 -----------------+
Correct?
>> 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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
