Re: Remote debugging of multithreaded programs using gdbserver

[Daniel Jacobowitz <drow at mvista dot com>]

Comments about the rest later, but:

On Thu, Apr 18, 2002 at 06:55:56PM +0530, Subhashini Nagarajan Rao wrote:
> Hi Daniel,
> 
> As you had stated there are instances of inheritance of the
> concepts in the implementation of the gdbserver from the native gdb. This
> is due to the fact that we want to get the code functionally correct and
> running
> and later revisions can be done to it. Reply to the comments follow.

You had a very thorough design document, and a design document ought to
consider the eventual goal and not the current step.  Otherwise you
just waste a lot of work.

> > >   8. Miscellaneous changes
> > >
> > >   When the user fires a 'thread <id>' command , switch to the specified
> > >   thread but a step after this was not able to tell the server that the
> > >   thread to be stepped is the new thread and not the previous one.
> Hence,
> > >   there is a need for the client, to remotely specify the current thread
> > >   in switch_to_thread(). However since switch_to_thread() is written
> >
> > I don't see anything here that requires information gdbserver does not
> > already have.  It knows the last thread stepped and the thread
> > requested.
> >
> When we switch from one thread to another as a result of 'thread' command
> the inferior_ptid gets updated to the new thread. Now, when I do a `next',
> in the native gdb,  all the threads are resumed and in this case the step
> signal will be given to the updated inferior_ptid. However, in the case
> remote
> debugging if I resume all the threads after the `thread' command by doing a
> next on the new thread I will be sending a Hc-1 packet and the server is not
> notified about the thread switch. To mention the current thread I need to
> send
> a Hc<id> packet so that the server will be informed about the current thread
> of
> execution and it will do a step on the correct thread. This is done by
> calling set_thread().

OK, I believe I see the problem.  It looks like a bug in core GDB; we
resume all threads so remote_resume does not communicate which one to
step.  I'll think about this for a bit.


-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer