Roland McGrath wrote:
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.)
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.
That's now done, dwarflint checks for value space mismatch. For every CU, I'm now getting this:
warning: .debug_info: DIE 0xb: in "compile_unit" attribute "name" has value of unexpected type "identifier".
Looking into values.cc, that's probably related to this:
unsigned int expected = expected_value_space
(dwarf_whatattr (thisattr ()), 0); // XXX need tag!
I tried to trick it by using (*reference()).tag() instead of the 0, but
that just seems to throw an exception "no reference value"
(DWARF_E_NO_REFERENCE). I didn't dig in that further.
PM
signature.asc
Description: OpenPGP digital signature
_______________________________________________ elfutils-devel mailing list [email protected] https://fedorahosted.org/mailman/listinfo/elfutils-devel
