This is the mail archive of the mailing list for the elfutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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).



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]