This is the mail archive of the elfutils-devel@sourceware.org mailing list for the elfutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: aranges


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

Attachment: signature.asc
Description: PGP signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]