From: Andrew Burgess <aburgess@redhat.com>
To: gdb-patches@sourceware.org
Cc: Andrew Burgess <aburgess@redhat.com>
Subject: [PATCH 6/7] gdb: record block end addresses while parsing DIEs
Date: Sun, 20 Jul 2025 11:20:45 +0100 [thread overview]
Message-ID: <47a4003bea404c60d9526cff04ef1e1df0f908e9.1753006060.git.aburgess@redhat.com> (raw)
In-Reply-To: <cover.1753006060.git.aburgess@redhat.com>
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 after the last commit deferred building the
address map. The optimised code fix ups require that we can map from
an address back to a block, something the address map is perfect for.
However, the optimised code fix ups will then adjust the block ranges,
which means the address map is out of date.
So, I saw a couple of choices, I could build the address map while
parsing the DIES (as if the previous commit had not occurred), use the
address map to lookup inline blocks, and then either update, or
rebuild the full address map. Or, I could defer building the address
map, and then create this "partial" address map that only holds the
interesting, inline, blocks. I felt that maintaining this
alternative, partial address map was probably cheaper, take a look at
how new entries are added to the addrmap class compared to this
gdb::unordered_map.
Currently, nothing is done with this information, the information is
recorded as the block ranges are recorded, 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 69f396c774a..c1c0d9fcaa2 100644
--- a/gdb/dwarf2/cu.h
+++ b/gdb/dwarf2/cu.h
@@ -269,6 +269,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<unrelocated_addr, struct block *> inline_block_ends;
+
private:
const char *m_producer = nullptr;
diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c
index 47fbccbdb08..992cf008da0 100644
--- a/gdb/dwarf2/read.c
+++ b/gdb/dwarf2/read.c
@@ -6057,6 +6057,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
@@ -9856,6 +9860,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
next prev parent reply other threads:[~2025-07-20 10:25 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-20 10:20 [PATCH 0/7] Inline Function Optimised Code Debug Improvements Andrew Burgess
2025-07-20 10:20 ` [PATCH 1/7] gdb: improve line number lookup around inline functions Andrew Burgess
2025-07-20 10:20 ` [PATCH 2/7] gdb: handle empty ranges for inline subroutines Andrew Burgess
2025-07-20 10:20 ` [PATCH 3/7] gdb: split dwarf line table parsing in two Andrew Burgess
2025-07-20 10:20 ` [PATCH 4/7] gdb: move block range recording into its own function Andrew Burgess
2025-07-20 10:20 ` [PATCH 5/7] gdb: create address map after parsing all DIE Andrew Burgess
2025-07-20 10:20 ` Andrew Burgess [this message]
2025-07-20 10:20 ` [PATCH 7/7] gdb: fix-up truncated inline function block ranges Andrew Burgess
2025-08-01 8:58 ` [PATCHv2 0/7] Inline Function Optimised Code Debug Improvements Andrew Burgess
2025-08-01 8:58 ` [PATCHv2 1/7] gdb: improve line number lookup around inline functions Andrew Burgess
2025-08-01 8:58 ` [PATCHv2 2/7] gdb: handle empty ranges for inline subroutines Andrew Burgess
2025-08-01 8:58 ` [PATCHv2 3/7] gdb: split dwarf line table parsing in two Andrew Burgess
2025-08-01 8:58 ` [PATCHv2 4/7] gdb: move block range recording into its own function Andrew Burgess
2025-08-01 8:58 ` [PATCHv2 5/7] gdb: create address map after parsing all DIE Andrew Burgess
2025-08-01 8:58 ` [PATCHv2 6/7] gdb: record block end addresses while parsing DIEs Andrew Burgess
2025-08-01 8:58 ` [PATCHv2 7/7] gdb: fix-up truncated inline function block ranges Andrew Burgess
2025-10-16 17:49 ` [PATCHv3 0/7] Inline Function Optimised Code Debug Improvements Andrew Burgess
2025-10-16 17:49 ` [PATCHv3 1/7] gdb: improve line number lookup around inline functions Andrew Burgess
2025-10-27 22:22 ` Tom Tromey
2025-12-17 14:32 ` Andrew Burgess
2025-12-17 14:48 ` Tom de Vries
2025-12-18 14:46 ` Andrew Burgess
2025-10-16 17:49 ` [PATCHv3 2/7] gdb: handle empty ranges for inline subroutines Andrew Burgess
2025-10-16 17:49 ` [PATCHv3 3/7] gdb: split dwarf line table parsing in two Andrew Burgess
2025-10-16 17:49 ` [PATCHv3 4/7] gdb: move block range recording into its own function Andrew Burgess
2025-10-27 22:45 ` Tom Tromey
2025-10-16 17:49 ` [PATCHv3 5/7] gdb: create address map after parsing all DIE Andrew Burgess
2025-10-27 22:56 ` Tom Tromey
2026-01-02 16:36 ` Andrew Burgess
2026-01-05 20:03 ` Tom Tromey
2026-01-05 21:37 ` Andrew Burgess
2026-01-06 0:53 ` Tom Tromey
2025-10-16 17:49 ` [PATCHv3 6/7] gdb: record block end addresses while parsing DIEs Andrew Burgess
2025-10-27 23:00 ` Tom Tromey
2025-10-16 17:49 ` [PATCHv3 7/7] gdb: fix-up truncated inline function block ranges Andrew Burgess
2026-02-04 10:43 ` [PATCHv3 0/7] Inline Function Optimised Code Debug Improvements Andrew Burgess
2025-08-01 15:41 ` [PATCH " Sam James
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=47a4003bea404c60d9526cff04ef1e1df0f908e9.1753006060.git.aburgess@redhat.com \
--to=aburgess@redhat.com \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox