Hi,
To get better feeling for how well line info is represented in dwarf. I
wrote two more die_checks. One to check that DW_AT_decl/call file, line
and column come in understandable pairs. That only found issues
in some test files, but none in practice with modern gcc. And another
that checks that all start addresses of code block dies are also
mentioned in the line info table. That one does produce some real
warnings. Spot checking reveals these are also the addresses at which
gdb gets somewhat confused at which source line the code really is.
I also added a small addition to dwarf::attribute_type. find_integrate
is something I keep writing myself each time. I didn't happen to use
them in these particular new tests, but I do use it during debugging
(for example to get at the name of a die construct). And it seemed
useful in general.
Cheers,
Mark
commit 849c6da0eeb1b453c7bb7ffea25a16c78d7e0a1b
Author: Mark Wielaard <mjw(a)redhat.com>
Date: Wed Apr 13 12:33:29 2011 +0200
dwarflint: new check_die_line_info die check.
Check that each code block start address is also mentioned in the
line table.
commit d7c3ae057ab527750d172173b8d2a8639be6e823
Author: Mark Wielaard <mjw(a)redhat.com>
Date: Wed Apr 13 12:26:44 2011 +0200
dwarflint: new check_die_decl_call.cc die_check.
Check that each decl or call attribute come in file/line and
column/line pairs.
commit 1f282b3fd8fcde13ba8acf21aca9e40e4328c222
Author: Mark Wielaard <mjw(a)redhat.com>
Date: Tue Apr 12 15:01:02 2011 +0200
Add elfutils::dwarf::attribute_type::find_integrate ().
Same as find (), but if the attribute name isn't found,
but there is is an abstract_origin or specification
attribute, then will try to find_integrate () the name
from that reference.
check_linkage_external_die.is_external () now uses it.