From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (wildebeest.demon.nl [212.238.236.112]) by sourceware.org (Postfix) with ESMTPS id F10F039878B9 for ; Wed, 4 Nov 2020 13:35:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org F10F039878B9 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mark@klomp.org Received: from tarox.wildebeest.org (tarox.wildebeest.org [172.31.17.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 5DBA630291AB; Wed, 4 Nov 2020 14:35:02 +0100 (CET) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id 095904014452; Wed, 4 Nov 2020 14:35:02 +0100 (CET) Message-ID: <8564728c1bfe56cb03ee7fb7de43bdf7e93c6acd.camel@klomp.org> Subject: Re: multi debug files and artificial module From: Mark Wielaard To: Sasha Da Rocha Pinheiro , "elfutils-devel@sourceware.org" Cc: Tim Haines , "bolo@cs.wisc.edu" Date: Wed, 04 Nov 2020 14:35:01 +0100 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.28.5 (3.28.5-10.el7) Mime-Version: 1.0 X-Spam-Status: No, score=-5.5 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: elfutils-devel@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Elfutils-devel mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2020 13:35:05 -0000 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 "" 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=3Dgeneric -march=3Dx86-64 -g -g -O2 -O2 > -fno-openmp -fno-openacc -fPIC -fstack-protector-strong -fltrans > -fplugin=3Dann > 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) +0x0000000000008030 > > high_pc (udata) 51811 (+0x0000000000014a93 > <.annobin_iscsi_extended_copy_task.end>) > stmt_list (sec_offset) 0