From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from barracuda.ebox.ca (barracuda.ebox.ca [96.127.255.19]) by sourceware.org (Postfix) with ESMTPS id 7FDC73896828 for ; Tue, 17 Nov 2020 19:12:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 7FDC73896828 X-ASG-Debug-ID: 1605640353-0c856e6cd513c0b0001-fS2M51 Received: from smtp.ebox.ca (smtp.ebox.ca [96.127.255.82]) by barracuda.ebox.ca with ESMTP id lgMRdx18Ip8y7U0e (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Nov 2020 14:12:33 -0500 (EST) X-Barracuda-Envelope-From: simon.marchi@polymtl.ca X-Barracuda-RBL-Trusted-Forwarder: 96.127.255.82 Received: from simark.localdomain (173-246-6-90.qc.cable.ebox.net [173.246.6.90]) by smtp.ebox.ca (Postfix) with ESMTP id 2B8AE441D66; Tue, 17 Nov 2020 14:12:33 -0500 (EST) From: Simon Marchi X-Barracuda-RBL-IP: 173.246.6.90 X-Barracuda-Effective-Source-IP: 173-246-6-90.qc.cable.ebox.net[173.246.6.90] X-Barracuda-Apparent-Source-IP: 173.246.6.90 To: gdb-patches@sourceware.org Cc: nilsgladitz@gmail.com, Simon Marchi Subject: [PATCH 3/4] gdb/dwarf: don't enqueue CU in maybe_queue_comp_unit if already expanded Date: Tue, 17 Nov 2020 14:12:30 -0500 X-ASG-Orig-Subj: [PATCH 3/4] gdb/dwarf: don't enqueue CU in maybe_queue_comp_unit if already expanded Message-Id: <20201117191231.2712629-4-simon.marchi@polymtl.ca> X-Mailer: git-send-email 2.29.1 In-Reply-To: <20201117191231.2712629-1-simon.marchi@polymtl.ca> References: <20201117191231.2712629-1-simon.marchi@polymtl.ca> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Barracuda-Connect: smtp.ebox.ca[96.127.255.82] X-Barracuda-Start-Time: 1605640353 X-Barracuda-Encrypted: DHE-RSA-AES256-SHA X-Barracuda-URL: https://96.127.255.19:443/cgi-mod/mark.cgi X-Barracuda-BRTS-Status: 1 X-Virus-Scanned: by bsmtpd at ebox.ca X-Barracuda-Scan-Msg-Size: 2764 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=8.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.85943 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Spam-Status: No, score=-13.6 required=5.0 tests=BAYES_00, GIT_PATCH_0, KAM_DMARC_QUARANTINE, KAM_DMARC_STATUS, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_SOFTFAIL, 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: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2020 19:12:37 -0000 The previous commit log described how items could be left lingering in the dwarf2_per_bfd::queue and how that could cause trouble. This patch fixes the issue by changing maybe_queue_comp_unit so that it doesn't put a CU in the to-expand queue if that CU is already expanded. This will make it so that when dwarf2_fetch_die_type_sect_off calls follow_die_offset and maybe_queue_comp_unit, it won't enqueue the target CU, because it will see the CU is already expanded. This assumes that if a CU is dwarf2_fetch_die_type_sect_off's target CU, it will have previously been expanded. I think it is the case, but I can't be 100% sure. If that's not true, the assertions added in the following patch will catch it, and it means we'll have to re-think a bit more how things work (it wouldn't be well handled at all today anyway). This fixes something else in maybe_queue_comp_unit that looks wrong. Imagine the DIEs of a CU are loaded in memory, but that CU is not expanded. In that case, maybe_queue_comp_unit will use this early return: /* If the compilation unit is already loaded, just mark it as used. */ dwarf2_cu *cu = per_objfile->get_cu (per_cu); if (cu != nullptr) { cu->last_used = 0; return 0; } ... so the CU won't be queued for expansion. Whether the DIEs of a CU are loaded in memory and whether that CU is expanded are two orthogonal things, but that function appears to mix them. So, move the queuing above that check / early return, so that if the CU's DIEs are loaded in memory but the CU is not expanded yet, it gets enqueued. gdb/ChangeLog: * dwarf2/read.c (maybe_queue_comp_unit): Check if CU is expanded to decide whether or not to enqueue it for expansion. Change-Id: Id98c6b60669f4b4b21b9be16d0518fc62bdf686a --- gdb/dwarf2/read.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c index 698fdd23c1a1..51cc94f6ce00 100644 --- a/gdb/dwarf2/read.c +++ b/gdb/dwarf2/read.c @@ -9101,19 +9101,19 @@ maybe_queue_comp_unit (struct dwarf2_cu *dependent_cu, return 0; } + if (!per_objfile->symtab_set_p (per_cu)) + { + /* Add it to the queue. */ + queue_comp_unit (per_cu, per_objfile, pretend_language); + } + /* If the compilation unit is already loaded, just mark it as used. */ dwarf2_cu *cu = per_objfile->get_cu (per_cu); if (cu != nullptr) - { - cu->last_used = 0; - return 0; - } + cu->last_used = 0; - /* Add it to the queue. */ - queue_comp_unit (per_cu, per_objfile, pretend_language); - - return 1; + return cu == nullptr; } /* Process the queue. */ -- 2.29.1