All cases that I've seen so far were suffixes of previous
example this is a typical case (in libX11):
[ 14fd] "/usr/src/debug/libX11-1.1.4/src"
[ 151d] ".4/src"
[ 1524] "xbutton"
dwarflint claims that 0x151d..0x1523 are unused. I'm thinking it's the
compiler squeezing the reference to ".4/src" into previous string, and
failing to garbage collect the fragment.
Ok, I see. It might actually be from debugedit.
Sorry, that should have been a "NULL abbrev," an abbrev
with code 0,
used for alignment purposes. The open office library contains sequences
of non-NULL abbrevs. These technically form empty abbreviation
sections, so maybe make it a warning instead?
Did you mean that it contains NULL abbrevs? There are no authentic
alignment requirements in .debug_abbrev either, so this can be treated
similarly to the string table padding.
The above is on dwarflint branch. I had a small battle with git
the merges. I think I didn't screw anything, all commits on master are
yours. monotone-viz was quite a bit better at showing inter-branch
relations, in gitk everything looks like a particularly messy subway
map. But a couple more commits and I'll have branches figured out :)
OTOH, there are probably many more people and web resources around to help
you with GIT. (I don't have any great secret wisdom on this to share.)
FWIW, the branch/merge state looks exactly correct to me.