This is the mail archive of the
mailing list for the elfutils project.
dwarf_getfuncs () and dwarf_func_inline_instances () vs partial_units
- From: Mark Wielaard <mjw at redhat dot com>
- To: elfutils-devel at lists dot fedorahosted dot org
- Date: Thu, 14 Mar 2013 11:52:46 +0100
- Subject: dwarf_getfuncs () and dwarf_func_inline_instances () vs partial_units
In some cases dwz might place a DW_TAG_subprogram in a partial_unit that
is then imported into different compile_units that use it for
Currently there is no way to get at these through dwarf_getfuncs ()
since that function only accepts DW_TAG_compile_unit DIEs, and doesn't
follow DW_TAG_import units.
If we change dwarf_getfuncs () to either accept a partial_unit DIEs or
by descending into imported_units the subprogram DIEs it returns will
have their Dwarf_CU point to the partial_unit. This means that
dwarf_func_inline_instances () for those DIEs will only return any
inlined_subroutines pointing to the subprogram inside the partial_unit
itself (if any). It will miss the inlined_subroutines in the
compile_units that import the partial_unit since it will start its
search in the func DIE (partial) unit.
Any thoughts on how (or if) we should fix this?
I think the easiest way to fix this is to make dwarf_getfuncs () recurse
into DW_TAG_imported_units and return any (top-level) subprogram DIE
that way. Then for dwarf_func_inline_instances () if we notice the func
DIE has a partial_unit as CU we just search all compile_unit CUs instead
of just the defining CU.
Should we also accept DW_TAG_partial_units as root for dwarf_getfuncs?
Any alternative approaches to solve this issue? I can imagine having a
dwarf_func_inline_instances () that takes a CU as argument to search in,
instead of the func defining CU. But that introduces a new interface and
would not be very intuitive for the user (though it might be more
efficient than searching all CUs).