From: Markus Metzger <markus.t.metzger@intel.com>
To: gdb-patches@sourceware.org
Cc: pedro@palves.net
Subject: [PATCH v2 1/6] gdb, btrace: fix pr19340
Date: Thu, 11 Apr 2024 05:25:59 +0000 [thread overview]
Message-ID: <20240411052604.87893-2-markus.t.metzger@intel.com> (raw)
In-Reply-To: <20240411052604.87893-1-markus.t.metzger@intel.com>
GDB fails with an assertion when stopping recording on a replaying thread
and then resuming that thread. Stopping recording left the thread
replaying but the record target is gone.
Stop replaying all threads in the selected inferior before stopping recording.
If the selected thread had been replaying, print the (potentially updated)
location.
I had to change the stepping test slightly to account for different
compilers generating slightly different debug information, so when
stepping the 'return 0' after 'record stop' I would end up in a different
location depending on which compiler I used. The test still covers all
stepping commands.
Fixes PR gdb/19340.
---
gdb/record-btrace.c | 17 +++++++++++++++++
gdb/testsuite/gdb.btrace/step.exp | 22 +++++++++++++++-------
2 files changed, 32 insertions(+), 7 deletions(-)
diff --git a/gdb/record-btrace.c b/gdb/record-btrace.c
index 0ef1dfbe652..1d946f9d3f2 100644
--- a/gdb/record-btrace.c
+++ b/gdb/record-btrace.c
@@ -414,11 +414,28 @@ record_btrace_target::stop_recording ()
{
DEBUG ("stop recording");
+ /* Remember the selected thread if it exists and is replaying. */
+ thread_info *curr = nullptr;
+ if (inferior_ptid.lwp_p ())
+ {
+ curr = inferior_thread ();
+ if (!btrace_is_replaying (curr))
+ curr = nullptr;
+ }
+
+ record_stop_replaying ();
record_btrace_auto_disable ();
for (thread_info *tp : current_inferior ()->non_exited_threads ())
if (tp->btrace.target != NULL)
btrace_disable (tp);
+
+ /* Print the updated location in case we had stopped a replaying thread. */
+ if (curr != nullptr)
+ {
+ curr->set_stop_pc (regcache_read_pc (get_thread_regcache (curr)));
+ print_stack_frame (get_selected_frame (), 1, SRC_AND_LOC, 1);
+ }
}
/* The disconnect method of target record-btrace. */
diff --git a/gdb/testsuite/gdb.btrace/step.exp b/gdb/testsuite/gdb.btrace/step.exp
index 0adc18bd924..ed6d2140bdd 100644
--- a/gdb/testsuite/gdb.btrace/step.exp
+++ b/gdb/testsuite/gdb.btrace/step.exp
@@ -31,18 +31,26 @@ if ![runto_main] {
# trace the call to the test function
with_test_prefix "record" {
gdb_test_no_output "record btrace"
- gdb_test "next"
+ gdb_test "step"
+ gdb_test "next 2"
}
# let's step around a bit
with_test_prefix "replay" {
- gdb_test "reverse-next" ".*main\.2.*" "reverse-next.1"
+ gdb_test "reverse-finish" ".*main\.2.*" "reverse-finish.1"
gdb_test "step" ".*fun4\.2.*" "step.1"
gdb_test "next" ".*fun4\.3.*" "next.1"
gdb_test "step" ".*fun2\.2.*" "step.2"
- gdb_test "finish" ".*fun4\.4.*" "finish.1"
- gdb_test "reverse-step" ".*fun2\.3.*" "reverse-step.1"
- gdb_test "reverse-finish" ".*fun4\.3.*" "reverse-finish.1"
- gdb_test "reverse-next" ".*fun4\.2.*" "reverse-next.2"
- gdb_test "reverse-finish" ".*main\.2.*" "reverse-finish.2"
+ gdb_test "reverse-finish" ".*fun4\.3.*" "reverse-finish.2"
+ gdb_test "reverse-step" ".*fun1\.2.*" "reverse-step.1"
+ gdb_test "finish" ".*fun4\.3.*" "finish.1"
+ gdb_test "reverse-next" ".*fun4\.2.*" "reverse-next.1"
+ gdb_test "reverse-finish" ".*main\.2.*" "reverse-finish.3"
+}
+
+# stop recording and try to step live (pr19340)
+with_test_prefix "live" {
+ gdb_test "record stop" "fun4\.4.*Process record is stopped.*"
+ gdb_test "reverse-next" "Target .* does not support this command.*"
+ gdb_test "step" ".*fun3\.2.*"
}
--
2.34.1
Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928
next prev parent reply other threads:[~2024-04-11 5:26 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-11 5:25 [PATCH v2 0/6] fix PR gdb/19340 Markus Metzger
2024-04-11 5:25 ` Markus Metzger [this message]
2024-04-11 5:26 ` [PATCH v2 2/6] gdb, btrace: simplify gdb.btrace/multi-inferior.exp Markus Metzger
2024-04-11 5:26 ` [PATCH v2 3/6] gdb, btrace: remove record_btrace_target::supports_*() Markus Metzger
2024-04-11 5:26 ` [PATCH v2 4/6] gdb, btrace: set wait status to ignore if nothing is moving Markus Metzger
2024-04-11 5:26 ` [PATCH v2 5/6] gdb, infrun: fix silent inferior switch in do_target_wait() Markus Metzger
2024-04-11 5:26 ` [PATCH v2 6/6] gdb, btrace, infrun: per-inferior run-control Markus Metzger
2024-05-03 5:25 ` [PING] [PATCH v2 0/6] fix PR gdb/19340 Metzger, Markus T
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=20240411052604.87893-2-markus.t.metzger@intel.com \
--to=markus.t.metzger@intel.com \
--cc=gdb-patches@sourceware.org \
--cc=pedro@palves.net \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).