Roland McGrath wrote:
But, I tend to think we are starting to bend over too much towards
the
buggy producers. Though we haven't investigated it yet, all overlaps sure
seem damn suspect to me.
I pushed .debug_ranges and .debug_loc validation today, and both of
these report /huge/ amounts of overlaps. I placed something on the wiki
(
https://fedorahosted.org/elfutils/wiki/SuspiciousDebuginfoCases).
dwarflint, readelf, addr2line, all of these relatively simple binaries
(the complex case being e.g. libjre or the OOo test case) produce lots
of diagnostics.
> Doing the above, I found a bug in <dwarf> where
dwarf_ranges could return
> 1 when there was nothing at all in the range list. The iterator would
> than have _m_offset of 1, but end()._m_offset would be 0, and the two
> wouldn't compare equal. That's fixed in ebd7af on the dwarf branch,
> where return value of 1 is handled specially.
I'm surely being extra dense this week, but I am confused about what the
problem was here. The calling sequence of dwarf_ranges is not special for
this case. Actually, I'm not even sure what you mean by "nothing at all".
If there is a DW_AT_ranges that points to an end of list entry, it returns
0 the first time. It only returns 1 when there was a lo/hi pair. So do
you mean that there was a lo/hi pair that were equal? I don't see how that
failed to work either, with the _m_begin == _m_end loop in operator++.
Hm, I'm reviewing the fix, and am having second thoughts. I see this in
ranges::const_iterator::operator *:
if (unlikely (_m_offset == 1))
throw std::runtime_error ("dereferencing end iterator");
Seeing that the end iterator has _m_offset == 0, the right place to fix
that bug is probably operator*.
In future, I'd like you to make any changes to the class
definitions on a
pending branch and ask me to review and merge it. Not that there aren't
plenty of bugs or that you won't have the right fixes. But I want to keep
close track of everything in that code while we iron it out.
Sure looks like a good idea.
PM