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