public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
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


  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).