From: Simon Marchi <simon.marchi@efficios.com>
To: gdb-patches@sourceware.org
Cc: Simon Marchi <simon.marchi@efficios.com>
Subject: [PATCH 02/12] gdb: clear inferior displaced stepping state on exec
Date: Tue, 10 Nov 2020 16:46:04 -0500 [thread overview]
Message-ID: <20201110214614.2842615-3-simon.marchi@efficios.com> (raw)
In-Reply-To: <20201110214614.2842615-1-simon.marchi@efficios.com>
When a process does an exec, all its program space is replaced with the
newly loaded executable. All non-main threads disappear and the main
thread starts executing at the entry point of the new executable.
Things can go wrong if a displaced step operation is in progress while
we process the exec event.
If the main thread is the one executing the displaced step: when that
thread (now executing in the new executable) stops somewhere (say, at a
breakpoint), displaced_step_fixup will run and clear up the state. We
will execute the "fixup" phase for the instruction we single-stepped in
the old program space. We are now in a completely different context,
so doing the fixup may corrupt the state.
If it is a non-main thread that is doing the displaced step: while
handling the exec event, GDB deletes the thread_info representing that
thread (since the thread doesn't exist in the inferior after the exec).
But inferior::displaced_step_state::step_thread will still point to it.
When handling events later, this condition, in displaced_step_fixup,
will likely never be true:
/* Was this event for the thread we displaced? */
if (displaced->step_thread != event_thread)
return 0;
... since displaced->step_thread points to a deleted thread (unless that
storage gets re-used for a new thread_info, but that wouldn't be good
either). This effectively makes the displaced stepping buffer occupied
for ever. When a thread in the new program space will want to do a
displaced step, it will wait for ever.
I think we simply need to reset the displaced stepping state of the
inferior on exec. Everything execution-related that existed before the
exec is now gone.
I tried to write a test where a non-main thread displaced-steps an exec
syscall, where things would hang due to the displaced step buffer not
getting released. However, due to PR 26754 [1], it is hard to make it
stable. So I'm not including a test for this patch. If you have an
idea for another way to test this without triggering this bug, I'd like
to hear it.
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=26754
gdb/ChangeLog:
* infrun.c (infrun_inferior_execd): New function.
(_initialize_infrun): Attach inferior_execd observer.
Change-Id: I1bbc8538e683f53af5b980091849086f4fec5ff9
---
gdb/infrun.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/gdb/infrun.c b/gdb/infrun.c
index d59f6945285..bb881f3510d 100644
--- a/gdb/infrun.c
+++ b/gdb/infrun.c
@@ -1528,6 +1528,12 @@ infrun_inferior_exit (struct inferior *inf)
inf->displaced_step_state.reset ();
}
+static void
+infrun_inferior_execd (inferior *inf)
+{
+ inf->displaced_step_state.reset ();
+}
+
/* If ON, and the architecture supports it, GDB will use displaced
stepping to step over breakpoints. If OFF, or if the architecture
doesn't support it, GDB will instead use the traditional
@@ -9509,6 +9515,7 @@ enabled by default on some platforms."),
gdb::observers::thread_stop_requested.attach (infrun_thread_stop_requested);
gdb::observers::thread_exit.attach (infrun_thread_thread_exit);
gdb::observers::inferior_exit.attach (infrun_inferior_exit);
+ gdb::observers::inferior_execd.attach (infrun_inferior_execd);
/* Explicitly create without lookup, since that tries to create a
value with a void typed value, and when we get here, gdbarch
--
2.28.0
next prev parent reply other threads:[~2020-11-10 21:46 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-10 21:46 [PATCH 00/12] Concurrent displaced stepping Simon Marchi
2020-11-10 21:46 ` [PATCH 01/12] gdb: add inferior_execd observable Simon Marchi
2020-11-25 1:28 ` Pedro Alves
2020-11-10 21:46 ` Simon Marchi [this message]
2020-11-25 1:28 ` [PATCH 02/12] gdb: clear inferior displaced stepping state on exec Pedro Alves
2020-12-01 4:27 ` Simon Marchi
2020-11-10 21:46 ` [PATCH 03/12] gdb: rename things related to step over chains Simon Marchi
2020-11-25 1:28 ` Pedro Alves
2020-11-25 13:16 ` Simon Marchi
2020-11-10 21:46 ` [PATCH 04/12] gdb: rename displaced_step_closure to displaced_step_copy_insn_closure Simon Marchi
2020-11-25 1:29 ` Pedro Alves
2020-11-10 21:46 ` [PATCH 05/12] gdb: rename displaced_step_fixup to displaced_step_finish Simon Marchi
2020-11-25 1:29 ` Pedro Alves
2020-11-10 21:46 ` [PATCH 06/12] gdb: introduce status enum for displaced step prepare/finish Simon Marchi
2020-11-11 23:36 ` Andrew Burgess
2020-11-25 13:17 ` Simon Marchi
2020-11-25 1:30 ` Pedro Alves
2020-11-25 13:20 ` Simon Marchi
2020-11-10 21:46 ` [PATCH 07/12] gdb: pass inferior to get_linux_inferior_data Simon Marchi
2020-11-25 1:30 ` Pedro Alves
2020-11-10 21:46 ` [PATCH 08/12] gdb: move displaced stepping types to displaced-stepping.{h, c} Simon Marchi
2020-11-25 1:30 ` Pedro Alves
2020-11-10 21:46 ` [PATCH 09/12] gdb: move displaced stepping logic to gdbarch, allow starting concurrent displaced steps Simon Marchi
2020-11-25 1:40 ` Pedro Alves
2020-11-25 19:29 ` Simon Marchi
2020-11-25 19:35 ` Simon Marchi
2020-11-26 14:25 ` Pedro Alves
2020-11-30 19:13 ` Simon Marchi
2020-11-26 14:24 ` Pedro Alves
2020-11-30 20:26 ` Simon Marchi
2020-11-10 21:46 ` [PATCH 10/12] gdb: change linux gdbarch data from post to pre-init Simon Marchi
2020-11-25 1:41 ` Pedro Alves
2020-11-10 21:46 ` [PATCH 11/12] gdb: make displaced stepping implementation capable of managing multiple buffers Simon Marchi
2020-11-25 1:41 ` Pedro Alves
2020-11-30 18:58 ` Simon Marchi
2020-11-30 19:01 ` Simon Marchi
2020-11-10 21:46 ` [PATCH 12/12] gdb: use two displaced step buffers on amd64/Linux Simon Marchi
2020-11-25 1:42 ` Pedro Alves
2020-11-25 6:26 ` Simon Marchi
2020-11-25 20:07 ` Simon Marchi
2020-11-25 20:56 ` Simon Marchi
2020-11-26 21:43 ` Simon Marchi
2020-11-26 22:34 ` Simon Marchi
2020-11-28 18:56 ` Pedro Alves
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=20201110214614.2842615-3-simon.marchi@efficios.com \
--to=simon.marchi@efficios.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).