Re: multi debug files and artificial module

[Mark Wielaard <mark@klomp.org>]

Hi Sasha,

On Thu, 2020-11-05 at 22:15 +0000, Sasha Da Rocha Pinheiro via
Elfutils-devel wrote:
> In libdw.h it says: /* The offset can be computed from the address.
>  */
> How do I get the CU DIE offset from the address? Only saving the
> first CU and subtracting it on the others to get the offset?

Yeah, that comment is correct, but not really that helpful. There are
two offsets that might matter. The start of Dwarf (.debug_info) offset
and the start of the Dwarf_CU offset. But getting either by hand is
some work since it depends on the size of the CU header, which can be
different based on the version and type of CU. You can get the
header_size when iterating through the CUs with dwarf_nextcu or
dwarf_next_unit but it is not easily available otherwise.

But given a Dwarf_Die you can get the offsets through dwarf_dieoffset
and dwarf_cuoffset.

Also note that since 0.178 there is dwarf_die_addr_die, which simply
takes the (main) Dwarf object and a Dwarf_Die addr.

/* Given a Dwarf_Die addr returns a (reconstructed) Dwarf_Die, or NULL
   if the given addr didn't come from a valid Dwarf_Die.  In particular
   it will make sure that the correct Dwarf_CU pointer is set for the
   Dwarf_Die, the Dwarf_Abbrev pointer will not be set up yet (it will
   only be once the Dwarf_Die is used to read attributes, children or
   siblings).  This functions can be used to keep a reference to a
   Dwarf_Die which you want to refer to later.  The addr, and the result
   of this function, is only valid while the associated Dwarf is valid.  */

Although the comment doesn't explicitly say so, this also works for
DIEs from the associated alt or split Dwarf objects associated with the
given Dwarf.

> When we go through the .debug_info using dwarf_nextcu, we are getting
> partial units too. How should we deal with them? If they're not
> actually CU, should they not be returned and only used internally by
> libdw in order to 'complete' the other CUs?

You should probably simply skip them because they will ultimately be
imported into a "real" compile unit. Note that there also is
dwarf_get_units () which will directly give you the unit_type
(DW_UT_compile, DW_UT_type or DW_UT_partial) so you can easily skipe
any you are not interested in.

> It seems that libdw is automatically searching and loading the
> supplemental dwz file. Given the following:
> 
> ** file .debug **
> <1><f0d>: Abbrev Number: 37 (DW_TAG_subprogram)
>     <f0e>   DW_AT_abstract_origin: <alt 0x5112>
>     <f12>   DW_AT_low_pc      : 0x8650
>     <f1a>   DW_AT_high_pc     : 229
>     <f1c>   DW_AT_frame_base  : 1 byte block: 9c      
>  (DW_OP_call_frame_cfa)
>     <f1e>   DW_AT_GNU_all_call_sites: 1
>     <f1e>   DW_AT_sibling     : <0x107b>
> ...
>  <4><5112>: Abbrev Number: 0
> 
> ** file dwz **
> <1><5112>: Abbrev Number: 81 (DW_TAG_subprogram)
>     <5113>   DW_AT_external    : 1
>     <5113>   DW_AT_name        : (indirect string, offset: 0x9852):
> iscsi_tcp_free_pdu
>     <5117>   DW_AT_decl_file   : 51
>     <5118>   DW_AT_decl_line   : 142
>     <5119>   DW_AT_decl_column : 1
>     <511a>   DW_AT_prototyped  : 1
>     <511a>   DW_AT_sibling     : <0x5135>
> 
> When I'm parsing f0d, libdw automatically fetches the abstract origin
> on the dwz file. But when we try to parse the abstract origin on our
> own it gives us the one in the same file, which is 0. Is it because
> we should look into the form of the DW_AT_abstract_origin? In this
> case seems to be the GNU_ref_alt, correct?

Yes, if the form is DW_FORM_GNU_ref_alt (or DW_FORM_ref_sup4 or
DW_FORM_ref_sup8 in DWARF5) then the "raw offset" is against the alt
file (which you can get with dwarf_getalt).

But I would recommend you simply use dwarf_formref_die to get the
Dwarf_Die since that has all the logic already to resolve the DIE
whether it is a "global" offset, a CU-relative offset, an alt-reference 
or a type signature.

Cheers,

Mark