I'll try to review the actual code soon. A few thoughts for now:
- It loads .debug_abbrev, doing checks for validity of various
fields along the way. LEB128s are checked for overflow. All reads are
checked that they don't pass outside the section data.
For LEB128 there is an additional warning check to do. That is for a
longer-than-necessary encoding. For ULEB128, that means any trailing bytes
all of whose low 7 bits are 0. For SLEB128, any that are all 1 when the
last high bit was 1 or are all 0 when the last high bit was 0.
This is not an invalid encoding, but is a red flag. Make it a warning
rather than error, and/or enable the check with a --strict flag.
DIEs whose abbreviation has_children are checked to actually have
This also is a strict warning rather an error. fpc used to generate DWARF
like this (maybe still does). It's suboptimal but technically kosher.
- String references are marked and holes of unused bytes in
.dwarf_str are reported.
This is going off all DW_FORM_strp uses? I guess that does cover it.
My first reaction was to think you can't find all references without
higher-level grokage of DIEs. But in fact the only references to the
string table are via DW_FORM_strp, I think.
This of course is also a warning only, since unused bytes are kosher.
The only hard errors are an offset too large, or if the last byte of
.debug_str is not zero (so the final string would be unterminated).
- Most of that can't be considered tested. I tried a couple
debuginfo files (emacs, libX11, libsc680lx from OpenOffice). debuginfo
files often seem to contain unused .debug_str bytes.
Check whether any unused bytes are not zero, and flag that distinctly. If
they are all zero, it's likely to be alignment padding that the linker or
assembler or compiler thought was necessary (though it isn't). You can
notice the highest power of two to which the first used offset after the
extra zeros is aligned, and mention that in the message. (In future, we
might add flags to suppress the warning
Non-zero DIEs followed by zero DIEs are reported for libsc680lx,
suspicious and likely a bug in lint. False positives of this type will
have to be fixed as the producer development proceeds.
Not sure I grok "nonzero DIEs followed by zero DIEs". Does this mean
haschildren=true in a DIE with no children? Or something else?
(What is a "zero DIE"?)
- The code sits on pmachata/dwarflint branch. My thinking is
when the producer branch is created, this branch gets merged in and
deleted, and further development will take place on producer branch.