From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5984 invoked by alias); 21 Apr 2019 06:29:26 -0000 Mailing-List: contact dwz-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: dwz-owner@sourceware.org Received: (qmail 5949 invoked by uid 48); 21 Apr 2019 06:29:22 -0000 From: "vries at gcc dot gnu.org" To: dwz@sourceware.org Subject: [Bug default/24468] dwz -m generates partial unit without import Date: Tue, 01 Jan 2019 00:00:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: dwz X-Bugzilla-Component: default X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: vries at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: nobody at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2019-q2/txt/msg00025.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=3D24468 --- Comment #1 from Tom de Vries --- So, what happens is this: the partial unit at 2b5 in the multifile contains= as first die: ... <1><2be>: Abbrev Number: 5 (DW_TAG_const_type) <2bf> DW_AT_type : <0x4c> ... which refers to: ... <1><4c>: Abbrev Number: 18 (DW_TAG_typedef) <4d> DW_AT_name : (indirect string, offset: 0x54c): size_t <51> DW_AT_decl_file : 1 <52> DW_AT_decl_line : 216 <53> DW_AT_type : <0x344> ... in another partial unit in the multifile. When matching dies in the input file against the dies in the multifile duri= ng finalize_multifile, we compare 2be to 394: ... <1><389>: Abbrev Number: 24 (DW_TAG_typedef) <38a> DW_AT_name : (indirect string, offset: 0x226): size_t <38e> DW_AT_decl_file : 2 <38f> DW_AT_decl_line : 216 <390> DW_AT_type : <0x14> <1><394>: Abbrev Number: 7 (DW_TAG_const_type) <395> DW_AT_type : <0x389> ... which then fails because of a mismatch in DW_FORM (DW_FORM_ref_addr vs DW_FORM_ref_udata). OTOH, the long double die in the input file matches the one in the multifil= e. Subsequently, we hit this in create_import_tree, and skip generating an imp= ort for the partial unit due to 2be not having a duplicate: ... if (unlikely (fi_multifile) && rdie->die_nextdup =3D=3D NULL) { pu->u1.cu_icu =3D NULL; continue; } ... OTOH, we need an import for the partial unit due to the long double, which = does have a duplicate. Tentative patch: ... @@ -5779,10 +5798,15 @@ create_import_tree (void) for (rdie =3D pu->cu_die->die_child; rdie->die_named_namespace; rdie =3D rdie->die_child) ; - if (unlikely (fi_multifile) && rdie->die_nextdup =3D=3D NULL) + if (unlikely (fi_multifile)) { - pu->u1.cu_icu =3D NULL; - continue; + while (rdie->die_nextdup =3D=3D NULL && rdie->die_sib) + rdie =3D rdie->die_sib; + if (rdie->die_nextdup =3D=3D NULL) + { + pu->u1.cu_icu =3D NULL; + continue; + } } npus++; if (pu->cu_version > new_pu_version) ... Using the tentative patch, we get the missing import in CU elf-init.c: ... <1><2e4>: Abbrev Number: 15 (DW_TAG_imported_unit) <2e5> DW_AT_import : ... and find again the missing long double with gdb: ... $ gdb 1 -ex "info types" -batch | egrep "long double|^File" File /usr/include/bits/types.h: File /usr/include/libio.h: File /usr/lib64/gcc/x86_64-suse-linux/7/include/stddef.h: File : typedef long double; ... --=20 You are receiving this mail because: You are on the CC list for the bug.