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] |
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] |