Hi there,
a rather large patch has landed on dwarf branch. This is a summary for those interested in writing dwarflint checks that are not me (hi Mark!)
The goal was to clean up the way we create location descriptors for reporting (the "wheres"). Until now we used single "struct where" with a bunch of fields: section, some addresses, and chain links. Because it turned out that we need to pinpoint various odd messages (such as .rel* sections, location expressions), section_id ended up holding a bunch of values that were not debuginfo-related at all. Then there was the added wrinkle of CU DIE being formatted differently from normal DIEs in case of aranges. It was all a bit hacky and full of exceptions.
So this is now gone. Instead, we have a top-level abstract "class locus" with a single interface "std::string format" and several sub-classes that take care of details. They are all used as structures, the abstract class is only necessary for passing generic loci references around, and ultimately to wr_message or wr_error. But if there ever is a need to hold a bunch of distinct loci in one array, they new'ing and later deleting them as is usual in C++ is obviously possible.
Most formatting stayed the way it was, but DIE and abbrev loci in particular were changed to report the attribute name as soon as it is known. This should make citations more clear:
warning: .debug_abbrev: abbr. 0x11, attr. endianity: attribute from later DWARF version. error: .debug_info: DIE 0x29, attr. decl_file: references .debug_line table, but CU DIE lacks DW_AT_stmt_list.
The interesting locus subclasses probably are section_locus, for forming arbitrary section pointers, and die_locus, for forming DIE references. die_locus can be initialized simply by debug_info_entry:
for (dwarf::debug_info_entry::children_type::const_iterator jt = children.begin (); jt != children.end (); ++jt) // ... wr_message (die_locus (*jt), mc_impact_3 | mc_die_other) // ...
Other loci subclasses (e.g. arange_locus) can be extended to allow similar initialization from high-level dwarf structures. Since they are just a bunch of classes implementing an interface, with comparatively little magic involved, it should be pretty straightforward.
PM
elfutils-devel@lists.fedorahosted.org