Re: Remote debugging of multithreaded programs using gdbserver

Daniel Jacobowitz
2002-04-18T14:56:13Z

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.