public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Kevin Buettner <kevinb@redhat.com>
To: <zhiyong.yan@windriver.com>
Cc: gdb-patches@sourceware.org, <tom@tromey.com>, luis.machado@arm.com
Subject: Re: [PATCH] gdbserver: Install single-step breakpoint for a pending thread whose last_resume_kind is resume_step
Date: Tue, 11 Jul 2023 11:42:55 -0700	[thread overview]
Message-ID: <20230711114034.5d2fe2cb@f37-zws-nv> (raw)
In-Reply-To: <20230703030458.1192525-1-zhiyong.yan@windriver.com>

Hi Zhiyong,

See my comments below; there's still one formatting nit, but I also
have a question about whether this is the right place to fix the bug
that you're seeing.

Also, I've added Luis to the CC list since he knows a lot more about
the ARM architecture than I do.

On Mon, 3 Jul 2023 11:04:58 +0800
<zhiyong.yan@windriver.com> wrote:

> From: Zhiyong Yan <zhiyong.yan@windriver.com>
> 
> Gdb should not assume pending threads always generate "a non-gdbserver trap event", for example "Signal 17" event could happen. Now that resume_stopped_resumed_lwps() -> may_hw_step() assumes that the break point must already exist, resume_one_thread() should ensure the software breaking point is installed although the thread is pending.
> 
> Signed-off-by: Zhiyong Yan zhiyong.yan@windriver.com
> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30387
> ---
>  gdbserver/linux-low.cc | 11 ++++++++++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/gdbserver/linux-low.cc b/gdbserver/linux-low.cc
> index e6a39202a98..7d8bbf71ddc 100644
> --- a/gdbserver/linux-low.cc
> +++ b/gdbserver/linux-low.cc
> @@ -4671,7 +4671,16 @@ linux_process_target::resume_one_thread (thread_info *thread,
>        proceed_one_lwp (thread, NULL);
>      }
>    else
> -    threads_debug_printf ("leaving LWP %ld stopped", lwpid_of (thread));
> +    {
> +      threads_debug_printf ("leaving LWP %ld stopped", lwpid_of (thread));
> +      if (thread->last_resume_kind == resume_step)
> +	{
> +	  /* If resume_step is required by GDB, 
> +	     install single-step breakpoint.  */
> +	  if (supports_software_single_step())

Formatting nit: you need a space between 'supports_software_single_step'
and the left paren.

> +	    install_software_single_step_breakpoints (lwp);
> +	}
> +    }
>  
>    thread->last_status.set_ignore ();
>    lwp->resume = NULL;

With regard to the change itself...

If the debugging printf is accurate, the LWP is being left in a
stopped state.  If that's the case, then why are software single step
breakpoints being inserted?  It seems to me that you'd only want
to insert these breakpoints when the thread is actually about to
resume.

That said, I have no doubt that this change works for you, so clearly
there's something going on which I do not understand.  I'd like to
understand the situation better before approving it.  Also, once you
have an explanation, please update the code comments and/or commit log
message as appropriate.  My personal preference is for a concise
explanation to be placed in the code comments with any additional,
longer winded explanations or examples being placed in the commit log
message.

Kevin


  parent reply	other threads:[~2023-07-11 18:43 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-03  3:04 zhiyong.yan
2023-07-10 12:46 ` Alexandra Petlanova Hajkova
2023-07-11  1:49   ` Yan, Zhiyong
2023-07-11 18:42 ` Kevin Buettner [this message]
2023-07-12  2:17   ` Yan, Zhiyong
     [not found]   ` <DS0PR11MB644704609A8C731570939D96E736A@DS0PR11MB6447.namprd11.prod.outlook.com>
2023-07-12  3:29     ` Yan, Zhiyong
2023-07-17  9:35   ` Luis Machado
2023-07-12  3:19 zhiyong.yan
2023-07-12  3:25 zhiyong.yan
2023-07-21 20:49 ` Kevin Buettner
2023-07-24 13:36   ` Yan, Zhiyong
2023-07-25  3:36     ` Kevin Buettner
     [not found]       ` <DS0PR11MB6447E74277EE65464375E086E703A@DS0PR11MB6447.namprd11.prod.outlook.com>
2023-07-25  6:32         ` Kevin Buettner
2023-07-25  6:50           ` Yan, Zhiyong
2023-07-25  7:05             ` Yan, Zhiyong
2023-07-26  3:58               ` Kevin Buettner
2023-07-26  6:30                 ` Yan, Zhiyong
2023-07-12  3:25 zhiyong.yan

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=20230711114034.5d2fe2cb@f37-zws-nv \
    --to=kevinb@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=luis.machado@arm.com \
    --cc=tom@tromey.com \
    --cc=zhiyong.yan@windriver.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).