From: Luis Machado via Gdb-patches <gdb-patches@sourceware.org>
To: <gdb-patches@sourceware.org>
Subject: [PATCH 13/17] [gdb/generic] corefile/bug: Use thread-specific gdbarch when dumping register state to core files
Date: Tue, 11 Apr 2023 05:26:54 +0100 [thread overview]
Message-ID: <20230411042658.1852730-14-luis.machado@arm.com> (raw)
In-Reply-To: <20230411042658.1852730-1-luis.machado@arm.com>
When we have a core file generated by gdb (via the gcore command), gdb dumps
the target description to a note. During loading of that core file, gdb will
first try to load that saved target description.
This works fine for almost all architectures. But AArch64 has a few
dynamically-generated target descriptions/gdbarch depending on the vector
length that was in use at the time the core file was generated.
The target description gdb dumps to the core file note is the one generated
at the time of attachment/startup. If, for example, the SVE vector length
changed during execution, this would not reflect on the core file, as gdb
would still dump the initial target description.
Another issue is that the gdbarch potentially doesn't match the thread's
real gdbarch, and so things like the register cache may have different formats
and sizes.
To address this, fetch the thread's architecture before dumping its register
state. That way we will always use the correct target description/gdbarch.
---
gdb/linux-tdep.c | 18 +++++++++++++++++-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/gdb/linux-tdep.c b/gdb/linux-tdep.c
index 1fc9cb6faee..6749a39cfc2 100644
--- a/gdb/linux-tdep.c
+++ b/gdb/linux-tdep.c
@@ -2091,12 +2091,28 @@ linux_make_corefile_notes (struct gdbarch *gdbarch, bfd *obfd, int *note_size)
stop_signal);
if (signalled_thr != nullptr)
- linux_corefile_thread (signalled_thr, &thread_args);
+ {
+ /* On some architectures, like AArch64, each thread can have a distinct
+ gdbarch (due to scalable extensions), and using the inferior gdbarch
+ is incorrect.
+
+ Fetch each thread's gdbarch and pass it down to the lower layers so
+ we can dump the right set of registers. */
+ thread_args.gdbarch = target_thread_architecture (signalled_thr->ptid);
+ linux_corefile_thread (signalled_thr, &thread_args);
+ }
for (thread_info *thr : current_inferior ()->non_exited_threads ())
{
if (thr == signalled_thr)
continue;
+ /* On some architectures, like AArch64, each thread can have a distinct
+ gdbarch (due to scalable extensions), and using the inferior gdbarch
+ is incorrect.
+
+ Fetch each thread's gdbarch and pass it down to the lower layers so
+ we can dump the right set of registers. */
+ thread_args.gdbarch = target_thread_architecture (thr->ptid);
linux_corefile_thread (thr, &thread_args);
}
--
2.25.1
next prev parent reply other threads:[~2023-04-11 4:28 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-11 4:26 [PATCH 00/17] SME support for AArch64 gdb/gdbserver on Linux Luis Machado via Gdb-patches
2023-04-11 4:26 ` [PATCH 01/17] [gdb/aarch64] Fix register fetch/store order for native AArch64 Linux Luis Machado via Gdb-patches
2023-04-11 4:26 ` [PATCH 02/17] [gdb/aarch64] refactor: Rename SVE-specific files Luis Machado via Gdb-patches
2023-04-11 4:26 ` [PATCH 03/17] [gdb/gdbserver] refactor: Simplify SVE interface to read/write registers Luis Machado via Gdb-patches
2023-04-11 4:26 ` [PATCH 04/17] [gdb/aarch64] sve: Fix return command when using V registers in a SVE-enabled target Luis Machado via Gdb-patches
2023-04-11 4:26 ` [PATCH 05/17] [gdb/aarch64] sme: Enable SME registers and pseudo-registers Luis Machado via Gdb-patches
2023-04-11 4:26 ` [PATCH 06/17] [gdbserver/aarch64] refactor: Adjust expedited registers dynamically Luis Machado via Gdb-patches
2023-04-11 4:26 ` [PATCH 07/17] [gdbserver/aarch64] sme: Add support for SME Luis Machado via Gdb-patches
2023-04-11 4:26 ` [PATCH 08/17] [gdb/aarch64] sve: Fix signal frame z/v register restore Luis Machado via Gdb-patches
2023-04-11 4:26 ` [PATCH 09/17] [gdb/aarch64] sme: Signal frame support Luis Machado via Gdb-patches
2023-04-11 4:26 ` [PATCH 10/17] [gdb/aarch64] sme: Fixup sigframe gdbarch when vg/svg changes Luis Machado via Gdb-patches
2023-04-11 4:26 ` [PATCH 11/17] [gdb/aarch64] sme: Support TPIDR2 signal frame context Luis Machado via Gdb-patches
2023-04-11 4:26 ` [PATCH 12/17] [binutils/aarch64] sme: Core file support Luis Machado via Gdb-patches
2023-04-11 4:26 ` Luis Machado via Gdb-patches [this message]
2023-04-11 4:26 ` [PATCH 14/17] [gdb/generic] corefile/bug: Fixup (gcore) core file target description reading order Luis Machado via Gdb-patches
2023-04-11 4:26 ` [PATCH 15/17] [gdb/aarch64] sme: Core file support for Linux Luis Machado via Gdb-patches
2023-04-11 4:26 ` [PATCH 16/17] [gdb/testsuite] sme: Add SVE/SME testcases Luis Machado via Gdb-patches
2023-04-11 4:26 ` [PATCH 17/17] [gdb/docs] sme: Document SME registers and features Luis Machado via Gdb-patches
2023-04-11 7:09 ` Eli Zaretskii via Gdb-patches
2023-04-11 7:22 ` Luis Machado via Gdb-patches
2023-04-12 12:04 ` [PATCH,v2 " Luis Machado via Gdb-patches
2023-04-13 7:57 ` [PATCH, v2 " Eli Zaretskii via Gdb-patches
2023-04-13 12:17 ` [PATCH,v2 " Luis Machado via Gdb-patches
[not found] ` <83leiv4xsc.fsf@gnu.org>
2023-04-13 16:34 ` Luis Machado via Gdb-patches
2023-04-13 17:45 ` Eli Zaretskii via Gdb-patches
2023-04-17 17:19 ` [PATCH,v3 " Luis Machado via Gdb-patches
2023-04-22 9:21 ` [PATCH, v3 " Eli Zaretskii via Gdb-patches
2023-04-26 15:00 ` [PATCH,v3 " Luis Machado via Gdb-patches
2023-04-26 16:11 ` Eli Zaretskii via Gdb-patches
[not found] ` <11f9bfb1-78cb-80db-fbc6-3262f0f9fdae@arm.com>
2023-04-27 9:10 ` Eli Zaretskii via Gdb-patches
2023-04-27 9:12 ` Luis Machado via Gdb-patches
2023-04-11 15:50 ` [PATCH 00/17] SME support for AArch64 gdb/gdbserver on Linux John Baldwin
2023-04-12 8:47 ` Willgerodt, Felix via Gdb-patches
2023-04-12 9:12 ` Luis Machado via Gdb-patches
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=20230411042658.1852730-14-luis.machado@arm.com \
--to=gdb-patches@sourceware.org \
--cc=luis.machado@arm.com \
/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