From: "Aktemur, Tankut Baris" <tankut.baris.aktemur@intel.com>
To: Andrew Burgess <aburgess@redhat.com>,
"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Cc: Mihails Strasuns <mihails.strasuns@intel.com>,
"Schimpe, Christina" <christina.schimpe@intel.com>
Subject: RE: [PATCH 4/8] gdb, infrun: refactor part of `proceed` into separate function
Date: Wed, 28 Jun 2023 08:47:46 +0000 [thread overview]
Message-ID: <DM4PR11MB73039262D5F4FC0B222F559CC424A@DM4PR11MB7303.namprd11.prod.outlook.com> (raw)
In-Reply-To: <a8040e117fb6396a82de4f3988c7026c833e789f.1687438786.git.aburgess@redhat.com>
On Thursday, June 22, 2023 3:17 PM, Andrew Burgess wrote:
> From: Mihails Strasuns <mihails.strasuns@intel.com>
>
> Split the thread resuming code from proceed into new function
> proceed_resume_thread_checked.
>
> Co-Authored-By: Christina Schimpe <christina.schimpe@intel.com>
> ---
> gdb/infrun.c | 148 +++++++++++++++++++++++++++------------------------
> 1 file changed, 79 insertions(+), 69 deletions(-)
>
> diff --git a/gdb/infrun.c b/gdb/infrun.c
> index 5b0257076f0..b10b7c59652 100644
> --- a/gdb/infrun.c
> +++ b/gdb/infrun.c
> @@ -3268,6 +3268,82 @@ check_multi_target_resumption (process_stratum_target *resume_target)
> }
> }
>
> +/* Helper function for `proceed`. Check if thread TP is suitable for
> + resuming, and, if it is, switch to the thread and call
> + `keep_going_pass_signal`. If TP is not suitable for resuming then this
> + function will just return without switching threads. */
> +
> +static void
> +proceed_resume_thread_checked (thread_info *tp)
> +{
> + if (!tp->inf->has_execution ())
> + {
> + infrun_debug_printf ("[%s] target has no execution",
> + tp->ptid.to_string ().c_str ());
> + return;
> + }
> +
> + if (tp->resumed ())
> + {
> + infrun_debug_printf ("[%s] resumed",
> + tp->ptid.to_string ().c_str ());
> + gdb_assert (tp->executing () || tp->has_pending_waitstatus ());
> + return;
> + }
> +
> + if (thread_is_in_step_over_chain (tp))
> + {
> + infrun_debug_printf ("[%s] needs step-over",
> + tp->ptid.to_string ().c_str ());
> + return;
> + }
> +
> + /* When handling a vfork GDB removes all breakpoints from the program
> + space in which the vfork is being handled, as such we must take care
> + not to resume any thread other than the vfork parent -- resuming the
> + vfork parent allows GDB to receive and handle the 'vfork done'
> + event. */
> + if (tp->inf->thread_waiting_for_vfork_done != nullptr)
> + {
> + if (target_is_non_stop_p ())
> + {
> + /* For non-stop targets, regardless of whether GDB is using
> + all-stop or non-stop mode, threads are controlled
> + individually.
> +
> + When a thread is handling a vfork, breakpoints are removed
> + from the inferior (well, program space in fact), so it is
> + critical that we don't try to resume any thread other than the
> + vfork parent. */
> + if (tp != tp->inf->thread_waiting_for_vfork_done)
> + {
> + infrun_debug_printf ("[%s] thread %s of this inferior is "
> + "waiting for vfork-done",
> + tp->ptid.to_string ().c_str (),
> + tp->inf->thread_waiting_for_vfork_done
> + ->ptid.to_string ().c_str ());
> + return;
> + }
> + }
> + else
> + {
> + /* For all-stop targets, when we attempt to resume the inferior,
> + we will in fact only resume the vfork parent thread, this is
> + handled in internal_resume_ptid, as such, there is nothing
> + more that needs doing here. */
I wonder if here we should do
gdb_assert (tp == tp->inf->thread_waiting_for_vfork_done);
-Baris
> + }
> + }
> +
> + infrun_debug_printf ("resuming %s",
> + tp->ptid.to_string ().c_str ());
> +
> + execution_control_state ecs (tp);
> + switch_to_thread (tp);
> + keep_going_pass_signal (&ecs);
> + if (!ecs.wait_some_more)
> + error (_("Command aborted."));
> +}
> +
> /* Basic routine for continuing the program in various fashions.
>
> ADDR is the address to resume at, or -1 for resume where stopped.
> @@ -3456,77 +3532,11 @@ proceed (CORE_ADDR addr, enum gdb_signal siggnal)
> resume_ptid))
> {
> switch_to_thread_no_regs (tp);
> -
> - if (!tp->inf->has_execution ())
> - {
> - infrun_debug_printf ("[%s] target has no execution",
> - tp->ptid.to_string ().c_str ());
> - continue;
> - }
> -
> - if (tp->resumed ())
> - {
> - infrun_debug_printf ("[%s] resumed",
> - tp->ptid.to_string ().c_str ());
> - gdb_assert (tp->executing () || tp->has_pending_waitstatus ());
> - continue;
> - }
> -
> - if (thread_is_in_step_over_chain (tp))
> - {
> - infrun_debug_printf ("[%s] needs step-over",
> - tp->ptid.to_string ().c_str ());
> - continue;
> - }
> -
> - /* If a thread of that inferior is waiting for a vfork-done
> - (for a detached vfork child to exec or exit), breakpoints are
> - removed. We must not resume any thread of that inferior, other
> - than the one waiting for the vfork-done. */
> - if (tp->inf->thread_waiting_for_vfork_done != nullptr
> - && tp != tp->inf->thread_waiting_for_vfork_done)
> - {
> - infrun_debug_printf ("[%s] another thread of this inferior is "
> - "waiting for vfork-done",
> - tp->ptid.to_string ().c_str ());
> - continue;
> - }
> -
> - infrun_debug_printf ("resuming %s",
> - tp->ptid.to_string ().c_str ());
> -
> - execution_control_state ecs (tp);
> - switch_to_thread (tp);
> - keep_going_pass_signal (&ecs);
> - if (!ecs.wait_some_more)
> - error (_("Command aborted."));
> - }
> - }
> - else if (!cur_thr->resumed ()
> - && !thread_is_in_step_over_chain (cur_thr))
> - {
> - /* In non-stop mode, if a there exists a thread waiting for a vfork
> - then only allow that thread to resume (breakpoints are removed
> - from an inferior when handling a vfork).
> -
> - We check target_is_non_stop_p here rather than just checking the
> - non-stop flag, though these are equivalent (all-stop on a
> - non-stop target was handled in a previous block, so at this
> - point, if target_is_non_stop_p then GDB must be running on
> - non-stop mode). By using target_is_non_stop_p it will be easier
> - to merge this block with the previous in a later commit. */
> - if (!(target_is_non_stop_p ()
> - && cur_thr->inf->thread_waiting_for_vfork_done != nullptr
> - && cur_thr->inf->thread_waiting_for_vfork_done != cur_thr))
> - {
> - /* The thread wasn't started, and isn't queued, run it now. */
> - execution_control_state ecs (cur_thr);
> - switch_to_thread (cur_thr);
> - keep_going_pass_signal (&ecs);
> - if (!ecs.wait_some_more)
> - error (_("Command aborted."));
> + proceed_resume_thread_checked (tp);
> }
> }
> + else
> + proceed_resume_thread_checked (cur_thr);
>
> disable_commit_resumed.reset_and_commit ();
> }
> --
> 2.25.4
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:[~2023-06-28 8:47 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-22 13:17 [PATCH 0/8] Some vfork related fixes Andrew Burgess
2023-06-22 13:17 ` [PATCH 1/8] gdb: catch more errors in gdb.base/foll-vfork.exp Andrew Burgess
2023-06-22 13:17 ` [PATCH 2/8] gdb: don't restart vfork parent while waiting for child to finish Andrew Burgess
2023-06-22 13:17 ` [PATCH 3/8] gdb: fix an issue with vfork in non-stop mode Andrew Burgess
2023-06-22 13:17 ` [PATCH 4/8] gdb, infrun: refactor part of `proceed` into separate function Andrew Burgess
2023-06-28 8:47 ` Aktemur, Tankut Baris [this message]
2023-07-04 15:24 ` Andrew Burgess
2023-06-22 13:17 ` [PATCH 5/8] gdb: don't resume vfork parent while child is still running Andrew Burgess
2023-06-22 13:17 ` [PATCH 6/8] gdb/testsuite: expand gdb.base/foll-vfork.exp Andrew Burgess
2023-06-22 13:17 ` [PATCH 7/8] gdb/testsuite: remove use of sleep from gdb.base/foll-vfork.exp Andrew Burgess
2023-06-22 13:17 ` [PATCH 8/8] gdb: additional debug output in infrun.c and linux-nat.c Andrew Burgess
2023-07-04 15:22 ` [PATCHv2 0/8] Some vfork related fixes Andrew Burgess
2023-07-04 15:22 ` [PATCHv2 1/8] gdb: catch more errors in gdb.base/foll-vfork.exp Andrew Burgess
2023-07-04 15:22 ` [PATCHv2 2/8] gdb: don't restart vfork parent while waiting for child to finish Andrew Burgess
2023-07-05 10:08 ` Aktemur, Tankut Baris
2023-07-04 15:22 ` [PATCHv2 3/8] gdb: fix an issue with vfork in non-stop mode Andrew Burgess
2023-07-04 15:22 ` [PATCHv2 4/8] gdb, infrun: refactor part of `proceed` into separate function Andrew Burgess
2023-07-04 15:22 ` [PATCHv2 5/8] gdb: don't resume vfork parent while child is still running Andrew Burgess
2023-07-18 20:42 ` Simon Marchi
2023-07-21 9:47 ` Andrew Burgess
2023-07-23 8:53 ` Andrew Burgess
2023-08-16 14:02 ` Andrew Burgess
2023-08-17 6:36 ` Tom de Vries
2023-08-17 7:01 ` Tom de Vries
2023-08-17 8:06 ` Tom de Vries
2023-08-17 8:22 ` Tom de Vries
2023-07-04 15:22 ` [PATCHv2 6/8] gdb/testsuite: expand gdb.base/foll-vfork.exp Andrew Burgess
2023-07-05 11:22 ` Aktemur, Tankut Baris
2023-07-04 15:22 ` [PATCHv2 7/8] gdb/testsuite: remove use of sleep from gdb.base/foll-vfork.exp Andrew Burgess
2023-07-04 15:22 ` [PATCHv2 8/8] gdb: additional debug output in infrun.c and linux-nat.c Andrew Burgess
2023-07-05 11:30 ` [PATCHv2 0/8] Some vfork related fixes Aktemur, Tankut Baris
2023-07-17 8:53 ` Andrew Burgess
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=DM4PR11MB73039262D5F4FC0B222F559CC424A@DM4PR11MB7303.namprd11.prod.outlook.com \
--to=tankut.baris.aktemur@intel.com \
--cc=aburgess@redhat.com \
--cc=christina.schimpe@intel.com \
--cc=gdb-patches@sourceware.org \
--cc=mihails.strasuns@intel.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).