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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits