I merged roland/dwarf_edit onto roland/dwarf-collector and removed the
I then merged roland/dwarf-collector with a squash commit. That branch is
now stale, but I'll leave it around for a while in case we want the recent
It compiles with instantiations from the dwarfcmp test code. I hope we can
do further changes with smaller commitable pieces and not do more big
squash merges. But I just thought the intermediate commits in those recent
temporary branches of mine were too messy to merge into the main history.
dwarf_edit seems in decent shape for little hacks now.
I'll next work on making dwarf_edit work in the -T tests.
That should just require references set using the tracker.
I've merged the tracker work in a squash commit. The roland/tracker branch
is now stale. I've left it there only because its last bits of history
include some hacks for debugging output that I might be sorry later if I
wound up needing to add them again from scratch.
The tracker should be vastly more efficient than before, even if you don't
count the new lack of infinite recursion eating your memory for circular
reference chains. Its algorithm is perhaps close to optimal in that it
shouldn't walk any part of the tree more than once, though certainly the
code is not especially optimal.
It seems to work well for dwarfcmp self tests, which are rather slow but
not too pathological. The -T tests are quite broken (crashing), because
the dwarf_edit/dwarf_output stuff has to be updated to actually support
refs now that we have the tracker to make it possible. In the meantime
you might want this in your working tree:
diff --git a/tests/run-dwarfcmp-self.sh b/tests/run-dwarfcmp-self.sh
index cce6641..0000000 100755
@@ -39,7 +39,7 @@ runtest()
if [ -f $file ]; then
run_one "$file" -i -q
run_one "$file" -i
- run_one "$file" -i -q -T
+# run_one "$file" -i -q -T
If someone were looking for a little thing to do that is a bit diversionary
but will help us all, some gdb/archer python pretty-printers for C++ dwarf
In particular, it would be nice to be able to see dwarf::debug_info_entry
or dwarf::debug_info_entry::children_type::const_iterator (or maybe even
just Dwarf_Die) as "DIE 0x1234" (scn offset). It's simple enough to do
what dwarf_dieoffset does without an inferior call. In the C++ layers it's
"simple" to get down to the Dwarf_Die using their internal fields.
I did a little fiddling to make this work:
dwarf_edit::compile_unit &cu = f.new_unit ();
cu.children ().push_back (dwarf_edit::debug_info_entry (DW_TAG_subprogram));
cu.attributes ()[DW_AT_name].source_file () = "source-file.c";
It's on roland/dwarf_edit which is based on roland/dwarf-collector.
Since dwarf_edit stuff like this is not a focus now, I won't try to
commit this until after we have merged in the dwarf-collector branch.
(I'm still working on roland/tracker and then will merge that first.)
It may need some substantial jiggering for .dwarf_constant () to work
right. The others might be OK as is, though some of the hairy ones might
not be constructible or assignable as they need to be.
I was experimenting with creating a dwarf file from scrach using
dwarf_edit, but gut stuck when I was unable to figure out how to add an
attribute to a die. So is that a use case that we don't care about, or
are the bits here and I just fail to see them?
dwarf_edit::debug_info_entry cudie (DW_TAG_compile_unit);
dwarf_edit::compile_unit u (cudie);
dwarf_edit::debug_info_entry x (DW_TAG_base_type);
x.attributes () [DW_AT_name] = /* now what ? */;
tst.compile_units ().push_back (u);