From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26788 invoked by alias); 23 Aug 2002 18:16:17 -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 26780 invoked from network); 23 Aug 2002 18:16:16 -0000 Received: from unknown (HELO TheWorld.com) (199.172.62.103) by sources.redhat.com with SMTP; 23 Aug 2002 18:16:16 -0000 Received: from shell.TheWorld.com (root@shell01.TheWorld.com [199.172.62.241]) by TheWorld.com (8.9.3/8.9.3) with ESMTP id OAA19064; Fri, 23 Aug 2002 14:16:12 -0400 Received: from localhost (qqi@localhost) by shell.TheWorld.com (8.9.3/8.9.3) with ESMTP id OAA81333838; Fri, 23 Aug 2002 14:16:12 -0400 (EDT) X-Authentication-Warning: shell01.TheWorld.com: qqi owned process doing -bs Date: Fri, 23 Aug 2002 11:16:00 -0000 From: Quality Quorum To: Andrew Cagney cc: Daniel Jacobowitz , Subject: Re: RFC: Two small remote protocol extensions In-Reply-To: <3D665B6B.4010201@ges.redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2002-08/txt/msg00293.txt.bz2 On Fri, 23 Aug 2002, Andrew Cagney wrote: > > On Thu, 22 Aug 2002, Andrew Cagney wrote: > > > > > >> Lets get rid of the easy one (...) `Hg': > >> > >> `` > >> > >> @item @code{Hg}@var{id} --- set general thread > >> @cindex @code{Hc} packet > >> > >> Select the general thread. Register and memory read and write > >> operations apply to the most recently selected general thread. > > > > ????? Memory is shared between threads, isn't it so ???? > > The above reflects GDB's current behavour (logical or not). This is yet another long overdue problem (I had hope it was fixed in recent releases) - gdb lumps together mult-process debugging with multi-tread debugging and it it does not excell in any of them. It seems to me that we have to handle multi-process debugging a-la vxWorks with a separate gdb instance per process and thus forget about it. > > When reading or writing memory, gdb specifies a thread. If it turns out > that the thread disappeared, GDB picks a thread, any thread (the > assumption being that all address spaces are pretty much similar). > > Mind you, I've seen thread implementations that implemented per-thread > local data using VM. It does not mean that everybody else should suffer, it is time to fix this youthful indiscretion. > > enjoy, > Andrew Thanks, Aleksey > > > > IMHO, a multi-process debugging is a very different animal from a > > multi-thread debugging and lumping them together only creates more > > problems. > > > > Thanks, > > > > Aleksey > > > > > > > > > >> @var{id}, a hex encoded cardinal, is the identifier of the selected thread. > >> > >> After a target stop, the general thread is reset to the thread > >> identifier of the stopped thread. > >> > >> @emph{Implementation note: The @code{Hg} packet can not be used to > >> determine the most recently selected thread (using the @samp{thread > >> @var{thread-id} command). This is because @value{GDBN} can cache > >> per-thread data and avoid the need to re-query the target on each > >> @samp{thread} command.} > >> > >> @c Note the word ``can'' is used, not ``does'' :-) > >> > >> Reply: > >> @table @samp > >> @item OK > >> for success > >> @item E00 > >> unspecified error > >> @c ESRCH --- no such proces/thread? > >> @item @samp{} > >> unsupported > >> @end table > >> > >> '' > >> > >> Andrew > >> > >> > > > >> > On Fri, Aug 16, 2002 at 10:42:42AM -0400, Andrew Cagney wrote: > >> > > > > >> >> >On Wed, May 01, 2002 at 10:25:43PM -0400, Daniel Jacobowitz wrote: > >> >> > > > > >> > > > > >> >> >>In making remote thread debugging work on GNU/Linux, I needed two > >> >> >>additions > >> >> >>to the remote protocol. Neither is strictly necessary, but both are > >> >> >>useful, > >> >> >>IMHO. > >> >> >> > >> >> >>They are: > >> >> >> > >> >> >> - two new replies to the continue/step packets, 'n' and 'x'. They > >> >> >>indicate thread creation and death respectively, and are asynchronous; > >> >> >>the target is not stopped when they are sent. > > > >> > > > > >> >> > > >> >> > > >> >> >This one got shouted down, I'm not going to bring it up again. > >> >> > > >> >> > > > > >> > > > > >> >> >> - A new 'Hs' packet, paralleling Hc and Hg. This sets the "step" > >> >> >> thread. > > > >> > > > > >> >> > >> >> How is ``Hs'' different to: > >> >> > >> >> Hc > >> >> s > > > >> > > >> > > >> > Hc has a definite meaning right now. It means, step ONLY this > >> > thread. That corresponds to set scheduler-locking (on|step). Hc0 will > >> > be sent if we are not using scheduler locking. > >> > > >> > I see nothing wrong with the current meaning of Hc. > >> > > >> > Also, Hs was never meant to INCLUDE the step command. It sets a thread > >> > context, that's all. > >> > > >> > > > > >> >> >This one, however, needs feedback. A user just reported a bogus > >> >> >SIGTRAP bug to me which is fixed by the above. > >> >> > > >> >> >To elaborate on the problem: right now we have two ways of specifying a > >> >> >thread to the remote agent. Hg specifies the "general" thread, and Hc > >> >> >specifies the "continue" thread. These correspond to inferior_ptid and > >> >> >resume_ptid, roughly. > >> >> > > >> >> >When we single-step, if we are not using some form of > >> >> >scheduler-locking, resume_ptid is 0. We don't tell the agent at that > >> >> >point what inferior_ptid is; it has to step _some_ thread, and it picks > >> >> >one, and if it doesn't pick the one GDB expected we get problems. > > > >> > > > > >> >> > >> >> Shouldn't it pick the current-thread. > > > >> > > >> > > >> > As above. > >> > > >> > > > > >> >> >We need to either: > >> >> > - Communicate inferior_ptid via Hg at this time > >> >> > - Communicate inferior_ptid via a new Hs explicitly > >> >> > > >> >> >I think the former makes sense. Here's a patch; what do you think of > >> >> >it? Also included is the patch for gdbserver; I'd send a separate > >> >> >patch along afterwards to remove the vestiges of Hs from my testing, > >> >> >which escaped in the original threads patch. > > > >> > > > > >> >> > >> >> No. general thread is really ``selected thread'' the thread for which > >> >> the [gG][pP] packets apply. It is not involved in thread scheduling. > > > >> > > >> > > >> > We need two thread markers to step correctly; I think using this one is > >> > more logical. If you prefer then the code in gdbserver to use Hs is > >> > already there. > >> > > >> > > > > >> >> Separate to this is the user interface issue of, if you select a > >> >> different thread, and then do a step, things get real confused (I think > >> >> GDB tries to step the current (or stop) thread). > > > >> > > >> > > >> > No, actually, gdbserver is what gets confused. You've said this > >> > several times, and the last time you said it I went to check. In all > >> > my tests, both local (lin-lwp) and remote (with Hs patch), everything > >> > stepped the selected thread gracefully. This already works. Even > >> > scheduler locking works. > >> > > >> > -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer > > > >> > >> > >