Make sure the highest address for the CU is marked as end_sequence. This is required by the DWARF spec, but some compilers forget and dwfl_module_getsrc depends on it. We could reject it as bad DWARF but the DWARF .debug_lines spec is much stricter than what compilers seem to output in practice.
Signed-off-by: Mark Wielaard mjw@redhat.com --- libdw/ChangeLog | 5 +++++ libdw/dwarf_getsrclines.c | 5 +++++ 2 files changed, 10 insertions(+)
diff --git a/libdw/ChangeLog b/libdw/ChangeLog index 16acf5c..12df9bb 100644 --- a/libdw/ChangeLog +++ b/libdw/ChangeLog @@ -1,3 +1,8 @@ +2013-03-25 Mark Wielaard mjw@redhat.com + + * dwarf_getsrclines.c (dwarf_getsrclines): Mark highest address as + end_sequence. + 2013-03-12 Mark Wielaard mjw@redhat.com
* dwarf_getsrcfiles.c (dwarf_getsrcfiles): Allow DW_TAG_partial_unit. diff --git a/libdw/dwarf_getsrclines.c b/libdw/dwarf_getsrclines.c index c24aebb..5a58b78 100644 --- a/libdw/dwarf_getsrclines.c +++ b/libdw/dwarf_getsrclines.c @@ -712,6 +712,11 @@ dwarf_getsrclines (Dwarf_Die *cudie, Dwarf_Lines **lines, size_t *nlines) cu->lines->info[i].files = files; }
+ /* Make sure the highest address for the CU is marked as end_sequence. + This is required by the DWARF spec, but some compilers forget and + dwfl_module_getsrc depends on it. */ + cu->lines->info[nlinelist - 1].end_sequence = 1; + /* Success. */ res = 0; }
Mark Wielaard mjw@redhat.com writes:
Make sure the highest address for the CU is marked as end_sequence. This is required by the DWARF spec, but some compilers forget and dwfl_module_getsrc depends on it. We could reject it as bad DWARF but the DWARF .debug_lines spec is much stricter than what compilers seem to output in practice.
For context: right now we assert when we encounter Dwarf like that, so this is certainly better.
I'm kind of split on this, a part of me would like to reject such Dwarf. But this is more helpful to the user, and even though this could result in a wrong answer, that's just garbage in-garbage out principle at works.
Thanks, PM
I think this change is fine but we should have dwarflint complain about such malformed DWARF and you should immediately report the bugs in any compilers known to produce it.
On Mon, 2013-03-25 at 14:27 -0700, Roland McGrath wrote:
I think this change is fine but we should have dwarflint complain about such malformed DWARF and you should immediately report the bugs in any compilers known to produce it.
Yes, I am trying to poke the compiler people. Sadly .debug_line seems to have a somewhat high percentage of weird quirks. The spec says that addresses in a sequence may only increases, but (also because of missing end_sequence markers) you will often find a line program jumps around a lot and you get multiple rows for the same address. The eu-readelf --debug-dump=decodedline support helps to spot them more easily.
Especially GCC not emitting prologue_end markers is a pain because that seems to be the cause of lots of "adhoc heuristics" on how to interpret these quirks.
There are already a couple of issues filed against this for GCC: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47471 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48827 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49906
I thought there was also a general bug about the missing DW_LNS_set_prologue_end but I cannot find it now.
Cheers,
Mark
prologue_end is a quality issue, and in general it's a hard problem. end_sequence is a format correctness issue. They're in different categories.
On Tue, Mar 26, 2013 at 03:14:31PM -0700, Roland McGrath wrote:
prologue_end is a quality issue, and in general it's a hard problem. end_sequence is a format correctness issue. They're in different categories.
Yes, agreed in theory, if there were just missing or misplaced prologue_end markers. But in practice GCC doesn't just omit prologue_end markers it has uses a (fragile) way to indicate prologue ends by creating duplicate rows for the same address. Which is a format correctness issue.
Cheers,
Mark
elfutils-devel@lists.fedorahosted.org
-
Mark Wielaard -
Petr Machata -
Roland McGrath