Most DWARFv5 files will parse perfectly fine using our current parser, with the notable exception of supplementary files (section 7.3.6 in the spec). The TL;DR on supplementary files are that they're shared objects for debug information; instead of every binary containing duplicate definitions for types like FILE (or even just the builtin types), the theory is that the cstdio could have its own supplementary file (containing its own type definitions) which our binary then references.

This will require a significant refactor in our plugin, but the version of it in my head will also be faster and more accurate in the end; We need to treat DWARF more like source code and do proper AST stuff to resolve types -- since that'll require completely virtualizing the DWARF graph, we can take the opportunity to add additional verification/optimization on the graph (and eliminate the incredible amount of duplicated information while we're loading it)...like a compiler. I realize it sounds overkill, but in hindsight it should've been obvious that a portable, platform/language-agnostic debug info system is effectively LLVM but exclusively for type and function info...except for the fact that it tries really hard to pretend that it's not.

It's also worth mentioning that while gimli supports DWARFv5, including supplementary files, it currently only supports a single supplementary file at a time. Even if they were to start supporting multiple supplementary files, I believe my described refactor would still result in a net improvement in speed and accuracy. It will also allow us to support Components.

I will note here, in protest to the powers the be, that the proclaimed goals to "reduce link time and executable size" with the introduction of supplementary files has not yet made its way into any files I've seen. In fact, I've found that using supplementary files tends to increase the number of stubs (which tend to contain more information than they need to), resulting in more duplicated information.