Hi Mark,
Thanks for your response.
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?
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?
It seems that libdw is automatically searching and loading the supplemental dwz
file. Given the following:
** file .debug **
<1>: Abbrev Number: 37 (DW_TAG_subprogram)
DW_AT_abstract_origin:
DW_AT_low_pc : 0x8650
DW_AT_high_pc : 229
DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa)
DW_AT_GNU_all_call_sites: 1
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?
Regards,
Sasha
From: Mark Wielaard
Sent: Wednesday, November 4, 2020 7:35 AM
To: Sasha Da Rocha Pinheiro ;
elfutils-devel@sourceware.org
Cc: Tim Haines ; b...@cs.wisc.edu
Subject: Re: multi debug files and artificial module
Hi Sasha,
On Tue, 2020-11-03 at 21:37 +, Sasha Da Rocha Pinheiro via
Elfutils-devel wrote:
> we are currently dealing with multiple separate debug files, the
> normal stripped ones put in .debug/ folder and now the ones generated
> by DWZ and put into .dwz/ folder.
> When loading a normal stripped debug files who has a dwz file, I saw
> the same DIE (same id) twice with different data. Would it be a bug
> in DWZ or a correct dwarf state?
> Also is "" the name of the following compilation unit? Or
> is it a bug in eu-redealf/libdw?
Looking at what you posted you are actually looking at 3 different
types of CU DIEs. The "normal" separate .debug DIEs. The supplemental
(dwz alt file) DIEs and LTO (gcc -flto generated) DIEs. For the last
ones (which have GNU GIMPLE as producer, the internal GCC
representation of the program) it is correct to have them marked
"artificial", these CUs contain common code/types from the objects
combined by LTO (Link Time Optimization). If by "same id" you mean
"offset" (the hex value in square brackets) then yes, DIE offsets in
separate files (Dwarf objects) can be the same. The DIEs from the
.debug file and the DIEs from the .multi (supplemental) file are
represented by different Dwarf objects and DIEs with the same offset in
separate Dwarf objects are different DIEs.
Cheers,
Mark
> Compilation unit at offset 946:
> Version: 4, Abbreviation section offset: 0, Address size: 8, Offset
> size: 4
> [ 3bd] compile_unit abbrev: 63
> producer (strp) "GNU GIMPLE 10.2.1 20200723
> (Red Hat 10.2.1-1) -m64 -mtune=generic -march=x86-64 -g -g -O2 -O2
> -fno-openmp -fno-openacc -fPIC -fstack-protector-strong -fltrans
> -fplugin=ann
> obin"
> language (data1) C99 (12)
> name (GNU_strp_alt) ""
> comp_dir (GNU_strp_alt)
> "/usr/src/debug/libiscsi-1.19.0-2.fc33.x86_64/lib"
> low_pc (addr) +0x8030
>
> high_pc (udata) 51811 (+0x00014a93
> <.annobin_iscsi_extended_copy_task.end>)
> stmt_list (sec_offset) 0
