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?
That's the use case that I imagine dwarf_edit will eventually be for.
(It's probably not really useful otherwise.) But it's not a priority
any time soon. I didn't really think about the details of attr_value
construction too much. If there are missing bits, we will add them.
dwarf_edit::debug_info_entry cudie (DW_TAG_compile_unit);
dwarf_edit::compile_unit u (cudie);
dwarf_edit::compile_unit u; // ()
should do the same. But there is:
dwarf_edit::compile_unit &u = tst.new_unit ();
for that (with less copying).
dwarf_edit::debug_info_entry x (DW_TAG_base_type);
For real use, we should probably add another entry point:
dwarf_edit::debug_info_entry &x = u.new_entry (DW_TAG_base_type);
x = u.new_entry (DW_TAG_base_type, u.children ().end ());
where you can pass an iterator to the specific insertion point.
(End would be the default, but you might use this to add an entry
between two existing ones.)
x.attributes () [DW_AT_name] = /* now what ? */;
I think the idea is:
x.attributes () [DW_AT_name].source_file ().name () = "foo.c";
But I don't think that actually works.
Maybe this does it, but probably there are more wrinkles.
diff --git a/libdw/c++/dwarf_edit b/libdw/c++/dwarf_edit
index 00698b5..2fd7a5b 100644
@@ -969,6 +969,8 @@ namespace elfutils
inline flavor &variant () const
+ if (_m_value == NULL)
+ _m_value = new flavor;
flavor *p = dynamic_cast<flavor *> (_m_value);
if (p == NULL)
throw std::runtime_error ("wrong value type");