> I put some time into that over the week. The code now includes maps of > expected attributes (per DIE tag), and expected forms (per attribute form).
You should not need the latter, at least not done in that way. The dwarf::location_attr interfaces already encode that knowledge, in dwarf::attr_value::what_space (c++/values.cc). Actually the knowledge is in c++/dwarf-knowledge.cc, which you might use directly. (That file is where I intended to have tables of expected children tags, etc. too.) > Attributes are checked by recursive iteration of the DIE tree. That > approach will be necessary for checking expected children, but > attributes, I think, would better be checked from abbreviations. But I > don't think that <dwarf> provides support for that. The only benefit to checking at the abbrev granularity is avoiding repetition. I don't think it's really worth the trouble for that. In the diagnostics, you want to cite the particular affected DIEs anyway. Rather, high-level checks use high-level interfaces. Abbrevs are a low-level encoding detail; at the "semantic level" they just don't matter at all. > Attribute form is not checked, because there's no way to obtain that > from <dwarf>. So the table is here, but it's not being used currently. Don't check for "expected form". Check for "expected value space". attr->what_space () returns a space or throws an exception for ambiguity. (The exception types still need to be worked out, but for now catching any exception from what_space () as meaning "unexpected" is fine.) The decoder is liberal in cases without ambiguity, so you still want to check the value_space returned against the expected_value_space () mask. But you can let it entirely take care of the name+form->value_space mapping. Thanks, Roland _______________________________________________ elfutils-devel mailing list [email protected] https://fedorahosted.org/mailman/listinfo/elfutils-devel
