From: Mark Wielaard <mark@klomp.org>
To: Sasha Da Rocha Pinheiro <darochapinhe@wisc.edu>,
"elfutils-devel@sourceware.org" <elfutils-devel@sourceware.org>
Cc: Tim Haines <thaines@astro.wisc.edu>,
"bolo@cs.wisc.edu" <bolo@cs.wisc.edu>
Subject: Re: multi debug files and artificial module
Date: Wed, 04 Nov 2020 14:35:01 +0100 [thread overview]
Message-ID: <8564728c1bfe56cb03ee7fb7de43bdf7e93c6acd.camel@klomp.org> (raw)
In-Reply-To: <BN6PR06MB31076376128E5A084CBCC8F9A6110@BN6PR06MB3107.namprd06.prod.outlook.com>
Hi Sasha,
On Tue, 2020-11-03 at 21:37 +0000, 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 "<artificial>" 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) "<artificial>"
> comp_dir (GNU_strp_alt)
> "/usr/src/debug/libiscsi-1.19.0-2.fc33.x86_64/lib"
> low_pc (addr) +0x0000000000008030
> <iscsi_free_discovery_addresses>
> high_pc (udata) 51811 (+0x0000000000014a93
> <.annobin_iscsi_extended_copy_task.end>)
> stmt_list (sec_offset) 0
next prev parent reply other threads:[~2020-11-04 13:35 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-03 21:37 Sasha Da Rocha Pinheiro
2020-11-04 13:35 ` Mark Wielaard [this message]
2020-11-05 22:15 ` Sasha Da Rocha Pinheiro
2020-11-09 17:09 ` Mark Wielaard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8564728c1bfe56cb03ee7fb7de43bdf7e93c6acd.camel@klomp.org \
--to=mark@klomp.org \
--cc=bolo@cs.wisc.edu \
--cc=darochapinhe@wisc.edu \
--cc=elfutils-devel@sourceware.org \
--cc=thaines@astro.wisc.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).