From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id mceKLjox8WgUNTkAWB0awg (envelope-from ) for ; Thu, 16 Oct 2025 13:54:02 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=IzJOiO95; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id B92531E0BA; Thu, 16 Oct 2025 13:54:02 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=ham autolearn_force=no version=4.0.1 Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 1DB741E047 for ; Thu, 16 Oct 2025 13:54:02 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id AE9C13857C7B for ; Thu, 16 Oct 2025 17:54:01 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org AE9C13857C7B Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=IzJOiO95 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id 34E12385843D for ; Thu, 16 Oct 2025 17:50:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 34E12385843D Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 34E12385843D Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1760637009; cv=none; b=BXmZS4YKhvn0QJeBN8EAh7Z0F2F9tNF57LkhNUjZ+fSej5FCcbRDN2DNSQLFV2txaGtyjASRxI6j6STHz7rw1n29DpSnuZ6FiIeu5oNAhDjhTIskletsNMsQzvNf5hNp19XmmFg7GE8lCU5w+ax81soo9hwyL1Zoq3h2aCX4H5U= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1760637009; c=relaxed/simple; bh=+QHkO9699X89mi1rcXgoGdjLMVZg4lYFRwHaWY9R6ek=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=QGAyUPb5YRTadHueM+UNeKCa6T1pBGSqe7Ji+k0CUQG7WC5U6m9hQID44/x8qN5waMBjtw66LcMKUP/22XsOE19qh3ZtQZEQTMOYZgiheGlxy8T4EwKYAqXUJhfIqN/7ukhhxdYgYUwOgMA0WIsXBsXSGmGLZ1/MigGbKeD1tRc= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 34E12385843D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1760637008; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=+1QPFNSgT348MzpkgsWBXpeLinEVqwVNpNzxsz7gOSQ=; b=IzJOiO95Ijoh9RtJHCUwmnnhayrfWiipRMeAxwXtm/RGJl8Bp1RR/agB4Ifuptb76XPIbA M5bEWJTUc+LqspJmR6B3RMNiNTm9k4HVUm1CpMgUmGyoykQzAEBYN/YmT6gd6BArT9dJ6N xIBjazYCQskQbkiL8sZTB7IA2AkBSiA= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-164--4X-Fm9NP2-oLAQyl0O0AA-1; Thu, 16 Oct 2025 13:50:07 -0400 X-MC-Unique: -4X-Fm9NP2-oLAQyl0O0AA-1 X-Mimecast-MFC-AGG-ID: -4X-Fm9NP2-oLAQyl0O0AA_1760637006 Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-47107fcb257so9918575e9.0 for ; Thu, 16 Oct 2025 10:50:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1760637006; x=1761241806; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=+1QPFNSgT348MzpkgsWBXpeLinEVqwVNpNzxsz7gOSQ=; b=ml951uiUTK0VA9njlMZcU2NPgsxSbPNiqK8VRV/t7wdpjp3E8HxF8KUYh6EwaAqeN1 18wT7yPsTvICzRXXDIeVhJ1UmiNSJP/mHY89FvrWTaPaGezOsDjglka1vCKQRzmE1D6e 0jmy0D6obmw2wqypMovwHnxE/GrN8SEC8oaYNMAvrhOny1EWSu+3I8Kna8HqYMr5H6+b vkx/47lsAvBCrESfc35TNUBGHL1uvdM0zCzO+PIyreUov32s359UchtOa+G+bvZ/vp57 MxlHWV16cC3QSvAIrJkeGGQ7ryHUdFqFZFC7/HWLtHKtCASLQtvkYpyhEPlREGyLbke4 MZJg== X-Gm-Message-State: AOJu0Yz09UezSQUP4TJd9SKpDqEdsALaPOuus/Bfi5vUTJb1j/7FfY6G vAkijzmnXHbYhIMy7re9UuZCkFEdyhVSxCtbto31V9G/jKmfRx+7/wBB6z0GS3pqSWTEz0LwWi9 xdUi7MxxuCoNNNVLF+DricEp/qkHtkENhd9MjJ6RRX5fTdVFcFYqU45W1d1m8Q66oc7WKRuO265 0cuV7zcycC38GqC7YDoVuGQvFFtctRr1EsaPHs3JTP810R2LA= X-Gm-Gg: ASbGncsZXlydCr3JKnlIKRGwk2fSbweVMWig+AT81pD3QOfQHQBr0kCWQS/dS8SAren X4IU8KPLHqtBZbIUmeHW1SRapZkvaUIYuAA1WEAoGt7SVA5mG2POVL5B+uGIBjOxgB5L5Pi7wQm ZeXq6JGdvzIowAzEqqAVtrHRp7rFp1c2F2LB/Bb5dJaH2r7BUmpq8nZlcvHbqsohspQv0UVsk2n YGp2CUZgYG5pKL53FK3/BLrm0d6Db4oPh1gZbfs37a8HvKgtB8LHzePwhy7tBg+WjiotYt3eZIx Ia+0Jm+/eJG3cOiIRnFblp/zPzkeScjyh/rMUP4B/SNEJ/MZnwnjAWmNYd5dwy1qXdtHlw== X-Received: by 2002:a05:6000:2389:b0:427:151:3db6 with SMTP id ffacd0b85a97d-42704d8e226mr762946f8f.24.1760637005730; Thu, 16 Oct 2025 10:50:05 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGkkaBPQ/aafehe1FmK+ECgsyT6UKffLbnTqN0zZkXUXdzkdtbblmOEUBNr+OZiPdgMQlvf2g== X-Received: by 2002:a05:6000:2389:b0:427:151:3db6 with SMTP id ffacd0b85a97d-42704d8e226mr762919f8f.24.1760637005063; Thu, 16 Oct 2025 10:50:05 -0700 (PDT) Received: from localhost ([31.111.84.207]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-426ce5cf790sm34631397f8f.28.2025.10.16.10.50.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Oct 2025 10:50:04 -0700 (PDT) From: Andrew Burgess To: gdb-patches@sourceware.org Cc: Andrew Burgess Subject: [PATCHv3 6/7] gdb: record block end addresses while parsing DIEs Date: Thu, 16 Oct 2025 18:49:52 +0100 Message-ID: <2827782df9c48c4ce7ab54e4ef38c97954926b1e.1760636870.git.aburgess@redhat.com> X-Mailer: git-send-email 2.47.1 In-Reply-To: References: MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: GMvmKSNSNSAA-qTtUwYuZxjoPrHGnlr1ejud9Dhppe0_1760637006 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: 8bit content-type: text/plain; charset="US-ASCII"; x-default=true X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org Continuing to work towards the goal of improving GDB's ability to debug optimised code, this commit stores a map from the end address of a block (or a block's sub-range) to the block pointer. This information is collected while parsing the DIEs. This new map is required as a consequence of the previous commit. The optimised code fix ups require that we can map from an address back to a block, something that the address map was perfect for, but the previous commit deferred building the address map until later on. The problem is that the optimised code fixes in the next commit require the address to block map, but also adjust block ranges, which invalidates the address to block map. We could try to build the full address to block early on, and then update it as the optimised code fixes are performed, but this is expensive. The solution I propose is to build a light weight, partial map, that only holds the interesting (inline) blocks. This partial map is only needed between reading the DIE and applying the optimised code fixes, after which it is done with, and as a consequence we don't need to update this map as the optimised code fixes adjust block ranges, this makes the partial map cheaper. This commit is all about building the new partial map. Currently, nothing is done with this information; the information is recorded as the block ranges are parsed, and then discarded after the line table has been built. But in the next commit, this will be used to help adjust the ranges of some inline blocks, and this will improve GDB's ability to debug optimised code. There should be no user visible changes after this commit. --- gdb/dwarf2/cu.h | 7 +++++++ gdb/dwarf2/read.c | 8 ++++++++ 2 files changed, 15 insertions(+) diff --git a/gdb/dwarf2/cu.h b/gdb/dwarf2/cu.h index 68010a060cc..6d16dd1512e 100644 --- a/gdb/dwarf2/cu.h +++ b/gdb/dwarf2/cu.h @@ -274,6 +274,13 @@ struct dwarf2_cu return m_producer; } + /* The end addresses for some inline blocks. For blocks with multiple + sub-ranges, this is the end address of every sub-range within the + block. These are the inclusive end addresses, that is, these are the + last addresses inside the block's ranges. Only the first block that + ends at any given address will be recorded. */ + gdb::unordered_map inline_block_ends; + private: const char *m_producer = nullptr; diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c index 023cb07edd8..fe8b202c6b2 100644 --- a/gdb/dwarf2/read.c +++ b/gdb/dwarf2/read.c @@ -6153,6 +6153,10 @@ read_file_scope (struct die_info *die, struct dwarf2_cu *cu) && cu->line_header != nullptr) dwarf_decode_lines (cu, unrel_low); + /* We no longer need to track the inline block end addresses. Release + memory associated with this. */ + cu->inline_block_ends.clear (); + /* Decode macro information, if present. Dwarf 2 macro information refers to information in the line number info statement program header, so we can only read it if we've read the header @@ -9952,6 +9956,10 @@ dwarf2_record_single_block_range (struct dwarf2_cu *cu, struct block *block, CORE_ADDR low, CORE_ADDR high, unrelocated_addr unrel_high) { + /* If this is the end of an inline block, then record its end address. */ + if (block->inlined_p () && block->function () != nullptr) + cu->inline_block_ends.insert ({unrel_high, block}); + cu->get_builder ()->record_block_range (block, low, high); } -- 2.47.1