Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@false.org>
To: gdb-patches@sources.redhat.com
Subject: [patch/gdbserver] Avoid a nasty little problem in the remote protocol T packet
Date: Sat, 28 Feb 2004 18:22:00 -0000	[thread overview]
Message-ID: <20040228182203.GA16995@nevyn.them.org> (raw)

The documentation for the T packet is not especially clear on when thread:
may be omitted.  Gdbserver has been assuming that if the thread was omitted,
then the same thread used for the previous T packet will be used again. 
This is, unfortunately, wrong; if no thread is supplied by number,
remote_wait returns inferior_ptid.  It's not practical to track everything
that GDB might do which changes inferior_ptid, since not all of them are
communicated to the remote target; so the only thing we can do is always
report the thread.

Without this, gdb could misinterpret which thread has stopped.  It then
may omit sending an Hg packet, request registers, and get the registers for
a different thread than it wants.  This results in info thread changing
the stack pointer.  schedlock.exp catches this - it's the "step without lock
changes thread" test.

Will commit in a bit.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

2004-02-28  Daniel Jacobowitz  <drow@mvista.com>

	* remote-utils.c (prepare_resume_reply): Always supply "thread:".

Index: gdb/gdbserver/remote-utils.c
===================================================================
RCS file: /big/fsf/rsync/src-cvs/src/gdb/gdbserver/remote-utils.c,v
retrieving revision 1.17
diff -u -p -r1.17 remote-utils.c
--- gdb/gdbserver/remote-utils.c	5 Jun 2003 14:26:58 -0000	1.17
+++ gdb/gdbserver/remote-utils.c	27 Feb 2004 20:54:11 -0000
@@ -609,7 +629,11 @@ prepare_resume_reply (char *buf, char st
 	  thread_from_wait = ((struct inferior_list_entry *)current_inferior)->id;
 	  if (debug_threads)
 	    fprintf (stderr, "Writing resume reply for %d\n\n", thread_from_wait);
-	  if (old_thread_from_wait != thread_from_wait)
+	  /* 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 || old_thread_from_wait != thread_from_wait)
 	    {
 	      general_thread = thread_from_wait;
 	      sprintf (buf, "thread:%x;", thread_from_wait);


             reply	other threads:[~2004-02-28 18:22 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-28 18:22 Daniel Jacobowitz [this message]
2004-02-29 16:48 ` Daniel Jacobowitz

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=20040228182203.GA16995@nevyn.them.org \
    --to=drow@false.org \
    --cc=gdb-patches@sources.redhat.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