= Work done last week:
* Time spent on elfutils: ~80%
* sibling correctness
* better handling of padding, more uniform messages
* implement validation of .debug_aranges
* a bunch of small fixes
* implement fine-grained message selection. Each message has a
category, which is an or of one or more category selectors (e.g.
mc_impact_3 | mc_bloat | mc_die_rel_sib). There are criteria for
acceptance and rejection of message: the message is rejected if category
& reject != 0 or if category & accept == 0. Not everything can be
expressed with this, but seems enough so far. Command line flags tweak
* installed 45G of debuginfo on office machine
= Work scheduled for this week:
* Expected time spent on elfutils: 80%
* Update wiki with current status.
* Still didn't get around to see how dwarflint does on the test
suite that Roland posted about. I did glimpse the results that Roland
posted, but need to do a better look. Or just use the local debuginfo
that I've installed last week.
* Implement low-level checks for other sections (actually today I've
already done debug_pubnames).
I've reorganized a bit to fix a braino I'd had, and added a big overview
comment to libdw/c++/dwarf.
I added a testing option to dwarfcmp, and made run-dwarfcmp-self.sh also
test that mode. This test is extremely slow now, but that is normal.
Under -T, dwarfcmp does the comparison work a dozen extra times, plus the
pure-memory object construction, so it's doing more than 12x the work for
The self-test passes, which is our second milestone (DwarfTasks 2.5),
though I have not yet done the exhaustive test run. (My spare machine had
a flaky disk, so I've just put different spare disks in it, reinstalled and
started the extraction from scratch again.)
Benjamin, the easy way to get the code is:
git clone git://git.fedorahosted.org/git/elfutils.git
git checkout -b dwarf origin/dwarf
git pull # Repeat later to get any new changes.
If you want to build it, do 'autoreconf -f -i'. Then normal conventions,
See libdw/c++/dwarf and please give me feedback on the fundamental API.
This code is very prototypey and many corners are not finished. I am not
yet worrying about where the template instantiations should be compiled and
all that. (If you tell me about best practices for that stuff, I will file
it away for a bit later. But I am not going to think about it real soon.)
I think the big comment explains the basic thinking behind the API style.
Much of the template-heavy stuff is motivated by comparing and copying
between the input virtual objects and the output pure-memory objects. The
writer implementation will involve another one or two such class trees that
are likewise copyable from these.
The only test case using the classes so far is src/dwarfcmp.cc, which uses
the input iterators and comparison operators. With -T, it tests the
templatized output constructors from input iterators, and the output
The organization of the classes is what I think makes sense, and that seems
(to me) to fit in maximally with the STL container model. (I tried to make
all my virtual containers look template-compatible with the STL containers.)
The details of how I implemented all the C++ magic is entirely just what I
got to work. Plenty of it didn't so much especially make sense to me, as I
just banged against what it might want until the compiler finally shut up.
In particular, things like the specificity of the template variants of
things and the ramifications of template operator functions vs template
operator methods are almost entirely mysterious to me. Anything that seems
insane and like it should be done another way, probably is and should be.
There are some places where I had to make a constructor public because of
some template weirdness generating errors from system header files. I
don't understand those at all.
The most interesting piece of the interface is not there yet (attr values).
So far we only have the containers, a full skeleton with no meat.
But I'm pretty happy with the results so far, if not the readability of the
class definitions. The test_writer code in dwarfcmp is sure readable though!
I feel reasonably confident that miscellaneous application code digesting
the data would be fairly easy to write (and read) now, just in that the
container interfaces seem "simple". I'd like a reality check on that
feeling. (For actual consumers, we are missing all the interesting
tree-oriented layer of stuff that would be built on this basic input model.)
All advice welcome.
Please review the roland/fixes-for-c++ branch, which (aside from merges)
just has commit 1f6d2010bb26b6bf5395a98651fce9a1a9141ac3 (Subject:).
The C++ wrapper throws an exception for error, and without this it
couldn't tell for dwarf_haschildren without doing something unclean.
Ok to merge?
In libdw/dwarf_error.c, I've noticed a work-around for gcc supposedly
not respecting __attribute__((unused)) when used on function. I don't
know how did previous code look like, that's even pre-monotone code, but
attaching __attribute__((unused)) at function declaration site does work
for me on F-9.
(For function definition, I think it used to work differently: the
attribute would be placed between the function type and the function
name. Now I have to place it before the function type. I'm guessing
this might have been the one change that triggered this workaround.)
pmachata/pending has a single commit that implements this. Please
consider for merge.
I moved the roland/dwarf-c++ branch to just be called "dwarf",
and merged pmachata/dwarflint into it. I decided we'll put the
new library code in libdw/c++/ and not give it a separate makefile.
The one file there hasn't changed yet and still stands to get largely
rewritten. We can easily rename it we want.
I also added the dwarflint-self test. It might break if you build without -g.
We should probably give dwarflint an "ok if no DWARF at all" option and
then use that in this test.
Petr, push directly on this branch for dwarflint changes unless you think
they might need special caution beyond the normal (eventual) code review.
(If you stop using an old personal branch and want to remove it from the
server, you can do "git push origin :my/branch".)
Without this patch, the following command is terminated due to an
invalid memory reference (SIGEGV):
ld -m elf_i386 -L /opt/XXX/lib -lfoo bar.o
Technically, this is due to how the function "open_along_path2"
handles the list of directories searched for object files and
open_along_path2 ([...], pathelement *path)
firstp = path;
path = path->next;
while ([...] && path != firstp));
The function "open_along_path2" assumes the field "next" of the last
element points to the first element.
src/ld.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/src/ld.c b/src/ld.c
index 4f587fe..162cb1e 100644
@@ -1189,6 +1189,9 @@ ld_new_searchdir (const char *dir)
ld_state.tailpaths->next = newpath;
ld_state.tailpaths = newpath;
+ /* Update the last element according to open_along_path2's assumption. */
+ ld_state.tailpaths->next = ld_state.paths;
./kdebindings-debuginfo-4.1.85-2.fc11.ppc64:usr:lib:debug:usr:lib64:python2.6:site-packages:PyKDE4:kutils.so.debug/log:warning: Abbreviation section unnecessarily terminated with sequence of abbrevs with code 0.
which are another version of the same .debug_abbrev issue. (I think this
shows why a uniform message for all padding cases would be better.)
Many examples like:
./lazarus-debuginfo-0.9.26-3.fc11.ppc64:usr:lib:debug:usr:lib64:lazarus:tools:lrstolfm.debug/log:warning: CU 0x897: Sequence of DIEs at 0x7f4d1ade28b2 unnecessarily terminated with NUL die.
This is an ill-composed message that should be a uniform message style for
padding. But it's also suspect because the offset is clearly bogus.
> I changed the wording thus:
> warning: abbrev 0x104b1c: unnecessary padding with zero bytes.
Please make this a uniform message for all the padding cases.
warning: excess zero padding in '.debug_abbrev' at offset 0x104b1c
so it exactly matches a msg for '.debug_str', etc.
A future refinement would be to just summarize with an "unnecessary zero
padding" or "nonzero bytes in unused portions" message per section (maybe
with a total byte count or something), and add an option to spit out a
message for every particular offsets.
> I've also added --gnu option that Ulrich mentioned. (elflint has
> --gnuld, but I expect the main culprit to be gcc in many cases, so I
> generalized the option to --gnu). The above message is only printed in
> non-gcc mode.
That's fine for now. In the code, please make the particular checks keyed
on a finer-grained toggle, i.e. a "padding" switch or one per section.
As I mentioned earlier, we'll later line all those up with particular
= Work done last week:
* Holidays, so nothing serious. Nit picking on dwarflint code.
= Work scheduled for this week:
* Expected time spent on elfutils: 80%
* Push dwarflint commit that I've done last week (I was offline so
couldn't do it right away, it slipped my mind today).
* See how dwarflint does on the test suite that Roland posted about.
* Checks for correct DW_AT_sibling attribute value
* Checks for other sections (aranges, ranges, locs)
The roland/unwind branch has readelf changes for CFI printing
that I did ages ago. I think mine made use of some new libdw
functions not merged yet, is why I never merged that.
It's worth comparing that branch's readelf changes with what
you've done to see if I did anything better. (I don't really
remember any particular details now.)
Was there anything in particular that spurred you to hack on this?
(Like working on some CFI new hackery?) Please post and/or wikiize
about anything you are working on, just so everybody knows what's afoot.