Re: [patch/gdbserver] Avoid a nasty little problem in the remote protocol T packet

[Daniel Jacobowitz <drow@false.org>]

On Sat, Feb 28, 2004 at 01:22:03PM -0500, Daniel Jacobowitz wrote:
> 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.

> 2004-02-28  Daniel Jacobowitz  <drow@mvista.com>
> 
> 	* remote-utils.c (prepare_resume_reply): Always supply "thread:".

I've committed this to HEAD.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer