From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8541 invoked by alias); 18 Apr 2002 14:56:13 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 8473 invoked from network); 18 Apr 2002 14:56:08 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 18 Apr 2002 14:56:08 -0000 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 16yDKt-0004zg-00 for ; Thu, 18 Apr 2002 10:56:35 -0400 Date: Thu, 18 Apr 2002 07:56:00 -0000 From: Daniel Jacobowitz To: gdb@sources.redhat.com Subject: Re: Remote debugging of multithreaded programs using gdbserver Message-ID: <20020418105635.A18461@nevyn.them.org> Mail-Followup-To: gdb@sources.redhat.com References: <075b01c1e6dc$92861960$68b17fc0@wipro.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <075b01c1e6dc$92861960$68b17fc0@wipro.com> User-Agent: Mutt/1.3.23i X-SW-Source: 2002-04/txt/msg00308.txt.bz2 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 ' 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 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