fix the DWARF

Posted Oct 2, 2024 19:19 UTC (Wed) by daroc (editor, #160859)
In reply to: fix the DWARF by roc
Parent article: BTF, Rust, and the kernel toolchain

Unfortunately, DWARF was not designed with extension in mind, which makes it difficult to add new types of information.

to post comments

fix the DWARF

Posted Oct 2, 2024 21:23 UTC (Wed) by roc (subscriber, #30627) [Link] (3 responses)

DWARF definitely was designed to be extensible! And that extensibilty has been used, a lot.

I won't claim its extensibilty has been particularly *well* designed, but it would be good to know what exactly is the problem here.

fix the DWARF

Posted Oct 4, 2024 15:02 UTC (Fri) by jemarch (subscriber, #116773) [Link] (2 responses)

An example of the kind of problems we face is the support for the declaration and type tags that the BPF verifier needs. New C attributes (btf_decl_tag and btf_type_tag) are added in order to annotate particular declarations and types with arbitrary strings. The interpretation of the strings is in this case up to the kernel, like "percpu" or "user" or "kernel". The verifier needs the annotated types in BTF, but to reach the BTF we are forced to convey the information via DWARF.

Now, it may seem that the perfect solution on the DWARF side would be to create a new DW_TAG_annotated_type DIE and link it in the DW_AT_Type chains. This would be indeed reflect the intended semantic perfectly, it would be also easy to implement. Unfortunately, the way DWARF is designed it would also break all DWARF reader in existence. You can't add a new kind of link to this chain in a way existing readers would just mindlessly skip it. It would have been nice if DWARF would have provided us with a DW_TAG_nop_type DIE, but it doesn't.

David Faust managed to find a backwards compatible way to workaround this particular situation, which seems to satisfy all involved parties (kernel, GCC, clang), but it is necessarily convoluted and ugly. It involves the creation of a new kind of DIE _and_ of a new DW_AT_annotation, and while it allows a great deal of node sharing in the DIE tree, it also leads to some duplication of data.

It is taking more than one year of discussions and several implementation attempts to get the tags in DWARF.

BTF got them in a day.

fix the DWARF

Posted Oct 4, 2024 19:58 UTC (Fri) by intelfx (subscriber, #130118) [Link]

> Now, it may seem that the perfect solution on the DWARF side would be to create a new DW_TAG_annotated_type DIE and link it in the DW_AT_Type chains. This would be indeed reflect the intended semantic perfectly, it would be also easy to implement. Unfortunately, the way DWARF is designed it would also break all DWARF reader in existence. You can't add a new kind of link to this chain in a way existing readers would just mindlessly skip it.

So it *is* extensible, just not backward-compatibly?

fix the DWARF

Posted Oct 5, 2024 4:13 UTC (Sat) by roc (subscriber, #30627) [Link]

It's not obvious from your description why you need a new type DIE. A new DWARF attribute could be applied to existing DWARF type or declaration DIEs and existing DWARF consumers ignore unknown attributes, as far as I know.

> It is taking more than one year of discussions and several implementation attempts to get the tags in DWARF.

Yes, the DWARF standardization process is a mess.

> BTF got them in a day.

Yeah, I understand that it's very attractive to have your own format that you control. (Of course if it lasts a long time, producers and consumers will multiply and eventually you'll have to have your own standards process, stability issues, etc.)

I'm a bit concerned that as consumers of compiler metadata proliferate over time and demand more of their own formats, the compiler maintenance burden will grow and so will the overhead at build time. It looks like in the future there will be projects that need to support debugging as well as tools that consume BTF and SFrame so will have to build with DWARF + BTF + SFrame + who knows what else, duplicating work and data.