Re: aranges

[Roland McGrath <roland at redhat dot com>]

> ... so does that mean that after the optimization, .debug_ranges and 
> .debug_aranges will not match?

Perhaps.  We can think about the validation rules when we think about
actually implementing that optimization.  Off hand, I'm thinking it makes
sense to extend the CU's ranges across the trailing padding after its real
text bits and coalesce (though not change the ranges of individual scopes),
in which case aranges would still be verbatim from ranges.

> I looked into the two warnings for DIE 0x6909, and the situation is:
>  - .debug_aranges have 0x409130..0x4097a5
>  - .debug_ranges have 0x409130..0x409156, 0x409160..0x4097a5
>  - .debug_ranges also have 0x409130..0x4097a5

One option would be to change dwarf::coalesce to handle overlaps too.  Then
the equality comparison amounts to "haspc true on the same set", which is
arguably the morally true test.  In that case, you wouldn't report anything
about .debug_aranges values in this case: it's equivalent to the CU's
ranges, so that's it's test.  Then the overlap reports for .debug_ranges
tell the story without repeating it.

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.

> So there's an overlap in .debug_ranges.  Dwarflint currently only
> validates .debug_aranges for overlaps, so the overlap is not flagged by
> earlier errors.  

If I were to do the detailed report on only one of the two, it would be
.debug_ranges, not .debug_aranges.

> If I understand it correctly, this also means that there's no coalescing
> taking place "behind the scenes", and mismatched ranges are flagged
> appropriately, even if they cover the same area.

There is dwarf::coalesce, used in the operator== for range_list and ranges.
But it only coalesces proper adjacencies (which are entirely nonanomalous),
not overlaps.

> 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++.

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.


Thanks,
Roland