From: Andrew Burgess <aburgess@redhat.com>
To: gdb-patches@sourceware.org
Cc: Andrew Burgess <aburgess@redhat.com>
Subject: [PATCH 4/5] gdb: remove pre-loop callback from gdbarch_read_core_file_mappings
Date: Sat, 14 Mar 2026 14:32:21 +0000 [thread overview]
Message-ID: <e289cbf51f6c4a75a1d1610be5572611117072d2.1773498341.git.aburgess@redhat.com> (raw)
In-Reply-To: <cover.1773498341.git.aburgess@redhat.com>
Currently only one target, Linux, implements
gdbarch_read_core_file_mappings, with
linux_read_core_file_mappings. There is one use of
gdbarch_read_core_file_mappings in corelow.c, and one direct use of
linux_read_core_file_mappings in linux-tdep.c.
The gdbarch_read_core_file_mappings takes two callbacks, a pre-loop
callback, which is called once, then a loop callback which is called
multiple times for each mapping that is discovered.
The only user of the pre-loop callback is in linux-tdep.c. Within
corelow.c, the pre-loop callback is not used.
In the next commit I plan to change linux_read_core_file_mappings, and
as a result of this change the use of linux_read_core_file_mappings in
linux-tdep.c will no longer be able to make use of the pre-loop
callback. This means that, after the next commit, there will be no
users of the pre-loop callback.
Additionally, the pre-loop callback takes an argument, the number of
mappings found.
After the next commit it is no longer clear what number we should pass
here as the next commit will introduce the idea of there being two
types of mapping, anonymous and non-anonymous. Should the number
passed to the pre-loop callback be the combined total? Or should we
count each separately?
I could try to answer this question.
Or I could just delete the pre-loop callback from
gdbarch_read_core_file_mappings.
This commit takes the second approach and deletes the callback.
As part of this work I've updated linux_core_info_proc_mappings, which
is the function that calls linux_read_core_file_mappings, so that the
pre-loop callback is no longer used. The lambda capture on the loop
callback needed to change from [=] to [&] with this commit so
`emitter` from the enclosing scope can be modified.
There is one subtle change of behaviour in
linux_core_info_proc_mappings after this commit. Previously,
linux_core_info_proc_mappings would print the table header so long as
the core file had a valid NT_FILE note, even if that note contained no
actual file mappings.
With the removal of the pre-loop callback I had a choice, either
always print the table header, or only print the table header if I saw
some entries being printed. I selected the second choice as that
seemed like the smallest change, but there is a change here. If a
user has a core file with an NT_FILE note containing no mapped files,
then the table header will no longer be printed. Hopefully this isn't
too disruptive.
This is a refactoring commit in preparation for the next one.
---
gdb/arch-utils.c | 1 -
gdb/arch-utils.h | 1 -
gdb/corelow.c | 10 ++--------
gdb/gdbarch-gen.c | 4 ++--
gdb/gdbarch-gen.h | 4 ++--
gdb/gdbarch.h | 5 +----
gdb/gdbarch_components.py | 1 -
gdb/linux-tdep.c | 41 +++++++++++++++------------------------
8 files changed, 23 insertions(+), 44 deletions(-)
diff --git a/gdb/arch-utils.c b/gdb/arch-utils.c
index 9d3dbfa2d81..f649cfae82c 100644
--- a/gdb/arch-utils.c
+++ b/gdb/arch-utils.c
@@ -1077,7 +1077,6 @@ void
default_read_core_file_mappings
(struct gdbarch *gdbarch,
struct bfd *cbfd,
- read_core_file_mappings_pre_loop_ftype pre_loop_cb,
read_core_file_mappings_loop_ftype loop_cb)
{
}
diff --git a/gdb/arch-utils.h b/gdb/arch-utils.h
index 670136c9cac..7d16b219106 100644
--- a/gdb/arch-utils.h
+++ b/gdb/arch-utils.h
@@ -375,7 +375,6 @@ extern std::string default_get_pc_address_flags (const frame_info_ptr &frame,
extern void default_read_core_file_mappings
(struct gdbarch *gdbarch,
struct bfd *cbfd,
- read_core_file_mappings_pre_loop_ftype pre_loop_cb,
read_core_file_mappings_loop_ftype loop_cb);
/* Default implementation of gdbarch_core_parse_exec_context. Returns
diff --git a/gdb/corelow.c b/gdb/corelow.c
index e540e44474b..d63dd5f8f0d 100644
--- a/gdb/corelow.c
+++ b/gdb/corelow.c
@@ -2130,14 +2130,8 @@ gdb_read_core_file_mappings (struct gdbarch *gdbarch, struct bfd *cbfd)
/* See linux_read_core_file_mappings() in linux-tdep.c for an example
read_core_file_mappings method. */
gdbarch_read_core_file_mappings (gdbarch, cbfd,
- /* After determining the number of mappings, read_core_file_mappings
- will invoke this lambda. */
- [&] (ULONGEST)
- {
- },
-
- /* read_core_file_mappings will invoke this lambda for each mapping
- that it finds. */
+ /* gdbarch_read_core_file_mappings will invoke this lambda for each
+ mapping that it finds. */
[&] (ULONGEST start, ULONGEST end, ULONGEST file_ofs,
const char *filename, const bfd_build_id *build_id)
{
diff --git a/gdb/gdbarch-gen.c b/gdb/gdbarch-gen.c
index 573f6eefc96..f3a038b4a51 100644
--- a/gdb/gdbarch-gen.c
+++ b/gdb/gdbarch-gen.c
@@ -5202,13 +5202,13 @@ set_gdbarch_get_pc_address_flags (struct gdbarch *gdbarch,
}
void
-gdbarch_read_core_file_mappings (struct gdbarch *gdbarch, struct bfd *cbfd, read_core_file_mappings_pre_loop_ftype pre_loop_cb, read_core_file_mappings_loop_ftype loop_cb)
+gdbarch_read_core_file_mappings (struct gdbarch *gdbarch, struct bfd *cbfd, read_core_file_mappings_loop_ftype loop_cb)
{
gdb_assert (gdbarch != NULL);
gdb_assert (gdbarch->read_core_file_mappings != NULL);
if (gdbarch_debug >= 2)
gdb_printf (gdb_stdlog, "gdbarch_read_core_file_mappings called\n");
- gdbarch->read_core_file_mappings (gdbarch, cbfd, pre_loop_cb, loop_cb);
+ gdbarch->read_core_file_mappings (gdbarch, cbfd, loop_cb);
}
void
diff --git a/gdb/gdbarch-gen.h b/gdb/gdbarch-gen.h
index 1ff02b1067c..dbc0a070b7c 100644
--- a/gdb/gdbarch-gen.h
+++ b/gdb/gdbarch-gen.h
@@ -1691,8 +1691,8 @@ extern void set_gdbarch_get_pc_address_flags (struct gdbarch *gdbarch, gdbarch_g
/* Read core file mappings */
-typedef void (gdbarch_read_core_file_mappings_ftype) (struct gdbarch *gdbarch, struct bfd *cbfd, read_core_file_mappings_pre_loop_ftype pre_loop_cb, read_core_file_mappings_loop_ftype loop_cb);
-extern void gdbarch_read_core_file_mappings (struct gdbarch *gdbarch, struct bfd *cbfd, read_core_file_mappings_pre_loop_ftype pre_loop_cb, read_core_file_mappings_loop_ftype loop_cb);
+typedef void (gdbarch_read_core_file_mappings_ftype) (struct gdbarch *gdbarch, struct bfd *cbfd, read_core_file_mappings_loop_ftype loop_cb);
+extern void gdbarch_read_core_file_mappings (struct gdbarch *gdbarch, struct bfd *cbfd, read_core_file_mappings_loop_ftype loop_cb);
extern void set_gdbarch_read_core_file_mappings (struct gdbarch *gdbarch, gdbarch_read_core_file_mappings_ftype *read_core_file_mappings);
/* Return true if the target description for all threads should be read from the
diff --git a/gdb/gdbarch.h b/gdb/gdbarch.h
index 356aae0fee8..7d0f46ab8e2 100644
--- a/gdb/gdbarch.h
+++ b/gdb/gdbarch.h
@@ -121,10 +121,7 @@ enum class memtag_type
allocation,
};
-/* Callback types for 'read_core_file_mappings' gdbarch method. */
-
-using read_core_file_mappings_pre_loop_ftype =
- gdb::function_view<void (ULONGEST count)>;
+/* Callback type for 'read_core_file_mappings' gdbarch method. */
using read_core_file_mappings_loop_ftype =
gdb::function_view<void (ULONGEST start,
diff --git a/gdb/gdbarch_components.py b/gdb/gdbarch_components.py
index 46283c1bd7d..e15163957ee 100644
--- a/gdb/gdbarch_components.py
+++ b/gdb/gdbarch_components.py
@@ -2717,7 +2717,6 @@ Read core file mappings
name="read_core_file_mappings",
params=[
("struct bfd *", "cbfd"),
- ("read_core_file_mappings_pre_loop_ftype", "pre_loop_cb"),
("read_core_file_mappings_loop_ftype", "loop_cb"),
],
predefault="default_read_core_file_mappings",
diff --git a/gdb/linux-tdep.c b/gdb/linux-tdep.c
index 45606015579..0eaf9597ad8 100644
--- a/gdb/linux-tdep.c
+++ b/gdb/linux-tdep.c
@@ -1134,11 +1134,6 @@ linux_info_proc (struct gdbarch *gdbarch, const char *args,
CBFD is the BFD of the core file.
- PRE_LOOP_CB is the callback function to invoke prior to starting
- the loop which processes individual entries. This callback will
- only be executed after the note has been examined in enough
- detail to verify that it's not malformed in some way.
-
LOOP_CB is the callback function that will be executed once
for each mapping. */
@@ -1146,7 +1141,6 @@ static void
linux_read_core_file_mappings
(struct gdbarch *gdbarch,
struct bfd *cbfd,
- read_core_file_mappings_pre_loop_ftype pre_loop_cb,
read_core_file_mappings_loop_ftype loop_cb)
{
/* Ensure that ULONGEST is big enough for reading 64-bit core files. */
@@ -1232,7 +1226,6 @@ linux_read_core_file_mappings
}
cbfd->build_id = orig_build_id;
- pre_loop_cb (count);
/* Vector to collect proc mappings. */
struct proc_mapping
@@ -1274,11 +1267,8 @@ linux_read_core_file_mappings
});
/* Call loop_cb with sorted proc mappings. */
- for (int i = 0; i < count; i++)
- {
- const auto &m = proc_mappings[i];
- loop_cb (m.start, m.end, m.file_ofs, m.filename, m.build_id);
- }
+ for (const auto &m : proc_mappings)
+ loop_cb (m.start, m.end, m.file_ofs, m.filename, m.build_id);
}
/* Implement "info proc mappings" for corefile CBFD. */
@@ -1290,21 +1280,22 @@ linux_core_info_proc_mappings (struct gdbarch *gdbarch, struct bfd *cbfd,
std::optional<ui_out_emit_table> emitter;
linux_read_core_file_mappings (gdbarch, cbfd,
- [&] (ULONGEST count)
- {
- gdb_printf (_("Mapped address spaces:\n\n"));
- emitter.emplace (current_uiout, 5, -1, "ProcMappings");
- int width = gdbarch_addr_bit (gdbarch) == 32 ? 10 : 18;
- current_uiout->table_header (width, ui_left, "start", "Start Addr");
- current_uiout->table_header (width, ui_left, "end", "End Addr");
- current_uiout->table_header (width, ui_left, "size", "Size");
- current_uiout->table_header (width, ui_left, "offset", "Offset");
- current_uiout->table_header (0, ui_left, "objfile", "File");
- current_uiout->table_body ();
- },
- [=] (ULONGEST start, ULONGEST end, ULONGEST file_ofs,
+ [&] (ULONGEST start, ULONGEST end, ULONGEST file_ofs,
const char *filename, const bfd_build_id *build_id)
{
+ if (!emitter.has_value ())
+ {
+ gdb_printf (_("Mapped address spaces:\n\n"));
+ emitter.emplace (current_uiout, 5, -1, "ProcMappings");
+ int width = gdbarch_addr_bit (gdbarch) == 32 ? 10 : 18;
+ current_uiout->table_header (width, ui_left, "start", "Start Addr");
+ current_uiout->table_header (width, ui_left, "end", "End Addr");
+ current_uiout->table_header (width, ui_left, "size", "Size");
+ current_uiout->table_header (width, ui_left, "offset", "Offset");
+ current_uiout->table_header (0, ui_left, "objfile", "File");
+ current_uiout->table_body ();
+ }
+
ui_out_emit_tuple tuple_emitter (current_uiout, nullptr);
current_uiout->field_core_addr ("start", gdbarch, start);
current_uiout->field_core_addr ("end", gdbarch, end);
--
2.25.4
next prev parent reply other threads:[~2026-03-14 14:36 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-14 14:32 [PATCH 0/5] Improved support for core files with missing NT_FILE note Andrew Burgess
2026-03-14 14:32 ` [PATCH 1/5] gdb/testsuite: improve corefile-no-threads.py script Andrew Burgess
2026-03-14 14:32 ` [PATCH 2/5] gdb/testsuite: restructure gdb.base/corefile-buildid.exp Andrew Burgess
2026-03-14 14:32 ` [PATCH 3/5] gdb: remove 'num' argument from gdbarch_read_core_file_mappings callback Andrew Burgess
2026-03-14 14:32 ` Andrew Burgess [this message]
2026-03-14 14:32 ` [PATCH 5/5] gdb/linux: handle missing NT_FILE note when opening core files Andrew Burgess
2026-04-23 22:08 ` Keith Seitz
2026-05-01 19:09 ` Andrew Burgess
2026-04-23 22:06 ` [PATCH 0/5] Improved support for core files with missing NT_FILE note Keith Seitz
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=e289cbf51f6c4a75a1d1610be5572611117072d2.1773498341.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