This is the mail archive of the
mailing list for the GDB project.
Re: Remote debugging of multithreaded programs using gdbserver
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: gdb at sources dot redhat dot com
- Date: Thu, 18 Apr 2002 10:56:35 -0400
- Subject: Re: Remote debugging of multithreaded programs using gdbserver
- References: <email@example.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
> 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.
> > > 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
> 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
> a Hc<id> packet so that the server will be informed about the current thread
> 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