From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by sourceware.org (Postfix) with ESMTPS id 1FAE03854816 for ; Thu, 25 Feb 2021 14:45:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 1FAE03854816 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tdevries@suse.de X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 3B9E6AFB5; Thu, 25 Feb 2021 14:45:44 +0000 (UTC) Date: Thu, 25 Feb 2021 15:45:42 +0100 From: Tom de Vries To: dwz@sourceware.org, jakub@redhat.com, mark@klomp.org Subject: [PATCH] Call reorder_dups ASAP Message-ID: <20210225144541.GA4270@delia> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Status: No, score=-12.3 required=5.0 tests=BAYES_00, GIT_PATCH_0, KAM_DMARC_STATUS, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: dwz@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Dwz mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2021 14:45:46 -0000 Hi, Currently, we call reorder_dups just before partial unit creation, and only for DIEs that will be copied. This approach causes a problem with reachable DIE propagation (which is done in partition_dups after phase 1): when a dup-chain that needs to be reordered (starts with ODR_DECL but also contains ODR_DEF) is marked as reachable during this propagation, propagation will stop at the ODR_DECL, while it should continue at the first ODR_DEF instead. Fix this by calling reorder_dups ASAP, just after computing the partitions. The problem can be detected using this assert: ... @@ -12563,6 +12563,8 @@ write_die { dw_cu_ref refdcu = die_cu (refd); value = refd->u.p2.die_new_offset; + assert (IMPLIES (cu->cu_kind == CU_PU, + die_cu (refd)->cu_kind == CU_PU)); assert (value && refdcu->cu_kind != CU_ALT); if (t->attr[j].form == DW_FORM_ref_addr) { ... Any comments? Thanks, - Tom Call reorder_dups ASAP 2020-01-25 Tom de Vries PR dwz/25424 * dwz.c (partition_dups_1): Move calling of reorder_dups ... (partition_dups): ... here. --- dwz.c | 10 +++------- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/dwz.c b/dwz.c index f435428..9172011 100644 --- a/dwz.c +++ b/dwz.c @@ -8134,13 +8134,6 @@ partition_dups_1 (dw_die_ref *arr, size_t nr_partitions, size_t *partitions, && (ignore_size || orig_size > new_size)); if (force) { - if (odr_active_p && odr_mode != ODR_BASIC) - for (k = i; k < j; k++) - { - if (second_phase && !arr[k]->die_ref_seen) - continue; - arr[k] = reorder_dups (arr[k]); - } dw_die_ref die, *diep; dw_cu_ref refcu = die_cu (arr[i]); dw_cu_ref partial_cu = pool_alloc (dw_cu, sizeof (struct dw_cu)); @@ -8474,6 +8467,9 @@ partition_dups (void) if (stats_p) stats->part_cnt += nr_partitions; + if (odr_active_p && odr_mode != ODR_BASIC) + for (i = 0; i < vec_size; ++i) + arr[i] = reorder_dups (arr[i]); if (partition_dups_1 (arr, nr_partitions, partitions, &first_partial_cu, &last_partial_cu, false)) {