I'm poking into .debug_loc. Currently the validation is done
portions referenced from .debug_info. I rewrote the code to do it the
way it's done in other cases: .debug_info references are remembered, and
used to cross-check connectivity later, during sequential scan of
Like the others, there is nothing actually specified about any spaces that
aren't pointed to from some *ptr attribute. But it's suspicious if there
is something other than necessary padding in between.
One example that I've found is
where the stream actually ends up screwed royally after offset 70dd,
the file ends up with dozens of unresolved location list references.
readelf -wloc shows implausible location expressions after 70dd, too.
Many debuginfo files from openoffice.org
suite show similar problems.
So... am I missing some arcane insider info (or just misreading the
spec), or are these actual errors in our DWARF files?
Sure looks like garbage to me. (Note eu-readelf -wloc crashes on this
file. I committed some related fixes, but it still needs robustified
In the mean time, I switched back to the old way of validation, but
attaching the patch (formed against 8aef81) in case anyone wants to see
on their own eyes.
Yeah, I think the way to handle this and all the CU-derived (*ptr attr)
sections like .debug_ranges is to only fully validate the chunks that some
*ptr attr points to. You don't need to check those at all until after the
structural checks on .debug_info pass, so you can have the full
connectivity info on hand. If pointed-to sections overlap or something,
it's probably useful to try to decode whatever the largest covered area is
to cite the details. But for holes in between properly-terminated
pointed-to chunks, I think you can just apply the "padding logic". i.e.,
just report suspiciously large holes and/or nonzero garbage in holes.
That yields a fairly concise report of what to look at by hand, and then
you can use eu-readelf -wloc if you want to try to decode the garbage.
This garbage needs to be investigated (don't suppress the case under --gnu
or anything). But we don't want to spend time on that right now this week.
While we're working on the tools, let's keep our focus on grokking enough
to be sure whether our tools are right and it's authentic garbage (I think
we're sure now for this case).
We should collect all the kinds of bogons we've noted on some wiki pages.
When someone gets time, they can look into each case and figure out the
bugs on the producer side. (We already figured out and filed a couple of
the trivial .debug_abbrev bugs.)