Re: [PATCH] minor fixes in remote.c

[Philippe GIACINTI <Philippe dot Giacinti at sxb dot bsf dot alcatel dot fr>]

Michael Snyder <msnyder@cygnus.com> wrote:
 > Philippe GIACINTI wrote:
 > > 
 > > Hi,
 > > 
 > > Here is a patch including minor fixes in file gdb/remote.c:
 > > 
 > >      * remote.c (record_currthread): must call `set_thread' to change
 > >      general thread, in order to let stub know we have changed it.
 > >      * remote.c (remote_read_bytes): when we need to read more memory
 > >      than max buffer size, we have to reserve space for leading $ and
 > >      trailing # + checksum (i.e.: 4 char)
 > > 
 > >     ---------------------------------------------------------------
 > > --- insight-20000314.old/gdb/remote.c   Fri Feb 18 18:00:18 2000
 > > +++ insight-20000314/gdb/remote.c       Fri Mar 17 09:00:54 2000
 > > @@ -742,7 +742,7 @@
 > >  record_currthread (currthread)
 > >       int currthread;
 > >  {
 > > -  general_thread = currthread;
 > > +  set_thread (currthread,1);
 > > 
 > >    /* If this is a new thread, add it to GDB's thread list.
 > >       If we leave it up to WFI to do this, bad things will happen.  */
 > 
 > Philippe,
 > 
 > I don't understand why this change should be necessary.
 > The only context from which this function, remote_currthread, 
 > is called is when the remote target sends GDB a message telling
 > GDB that the current thread has changed.  Why should GDB then
 > need to turn around and pass the same information back to
 > the remote target?  I should take it for granted that the
 > remote target already knows this (having just told it to us).
 > 
Michael,

According to the remote protocol, the remote side only has to know the
`general' and `continue' threads, there is no notion of `current' thread.
In the current implementation of gdbserver, there is no current thread, and it
works because the stub code always gets info from the same thread 
(`inferior_pid'). In a multi-threaded context it is not possible without being
informed that the `general' thread has changed.
IMHO it is a good thing not to have to record the current thread in the remote
side and let the host side (gdb) decide which thread will be inspected and 
which thread will continue, it will otherwise be a useless limitation of the
protocol. This way it could be possible to inspect one thread without changing
the current thread in gdb ...

Best regards.
-- 
Philippe Giacinti - Alcatel Business Systems - PCD/SMB/SWPCC - CC S0645
1, route du Dr Albert Schweitzer - 67408 Illkirch Cedex - FRANCE
Tel: +33 (0)3.90.67.62.10 - Fax: +33 (0)3.90.67.77.93
mailto:Philippe.Giacinti@sxb.bsf.alcatel.fr