This is the mail archive of the
elfutils-devel@sourceware.org
mailing list for the elfutils project.
Re: dwarflint
- From: Roland McGrath <roland at redhat dot com>
- To: elfutils-devel at lists dot fedorahosted dot org
- Date: Tue, 16 Dec 2008 14:30:53 -0800
- Subject: Re: dwarflint
> All cases that I've seen so far were suffixes of previous strings. For
> 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 about
> 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.
Thanks,
Roland