public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Pedro Alves <pedro@palves.net>
To: "Denio, Mike" <miked@ti.com>, "gdb@sourceware.org" <gdb@sourceware.org>
Subject: Re: RiscV GDB remote protocol seems to expect stop reply to change Hg in all-stop mode
Date: Fri, 8 Apr 2022 22:41:17 +0100	[thread overview]
Message-ID: <12dff0f1-86cf-6e73-e0bb-0e6a09ab5f83@palves.net> (raw)
In-Reply-To: <f29bbaba8a5048f68b708fd739b1d2f3@ti.com>

On 2022-04-08 16:36, Denio, Mike via Gdb wrote:
> I noticed that in all stop mode, GDB expects the current Hg thread to be changed to the thread reported in the stop reply message, without sending an Hg command. This can most easily be seen by using the "i threads" command. GDB will read the registers of each (non-current) thread using 'Hg' / 'g', so it can display the PC location in the threads list. However, after a stop message, GDB appears to assume that the Hg thread is set to the current thread, even though it changed the Hg thread during 'i threads'. I could not find where this was documented.

I could swear this was documented, but I can't actually find it either.  This has "always" been this way, AFAIK.

In GDB's remote_target::wait_as, you can see that GDB calls record_currthread to make the Hg thread
match the event thread.

In GDBserver, we have this, in prepare_resume_reply:

	    /* This if (1) ought to be unnecessary.  But remote_wait
	       in GDB will claim this event belongs to inferior_ptid
	       if we do not specify a thread, and there's no way for
	       gdbserver to know what inferior_ptid is.  */
	    if (1 || cs.general_thread != ptid)
	      {
		int core = -1;
		/* In non-stop, don't change the general thread behind
		   GDB's back.  */
		if (!non_stop)
		  cs.general_thread = ptid;

I actually remember running into this comment that if (1) when I started
working in gdbserver, and I may have learned this from the code instead of
from the manual.  Non-stop was added later, and changing the current thread
when an event is reported is just completely incompatible with the asynchronous
way of non-stop RSP stop events, so I added that if (!non_stop).  I guess I didn't
realize back then that that should also be documented somewhere.

If no one beats me to it, I'll clarify this in the manual when I have a chance.

> 
> The 'fix' for me was to assume both Hg and Hc are auto-changed to whatever thread is reported in the stop reply when in all-stop mode.

GDB only auto-changes the Hg thread, see record_currthread.

  reply	other threads:[~2022-04-08 21:41 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-08 15:36 Denio, Mike
2022-04-08 21:41 ` Pedro Alves [this message]
2022-04-08 21:56   ` [EXTERNAL] " Denio, Mike

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=12dff0f1-86cf-6e73-e0bb-0e6a09ab5f83@palves.net \
    --to=pedro@palves.net \
    --cc=gdb@sourceware.org \
    --cc=miked@ti.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).