From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20900 invoked by alias); 9 Apr 2005 13:36:00 -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 20709 invoked from network); 9 Apr 2005 13:35:45 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 9 Apr 2005 13:35:45 -0000 Received: from drow by nevyn.them.org with local (Exim 4.50 #1 (Debian)) id 1DKG7i-000193-5B; Sat, 09 Apr 2005 09:35:42 -0400 Date: Sat, 09 Apr 2005 13:36:00 -0000 From: Daniel Jacobowitz To: Eli Zaretskii Cc: gdb@sources.redhat.com Subject: Re: vCont request Message-ID: <20050409133541.GA4061@nevyn.them.org> Mail-Followup-To: Eli Zaretskii , gdb@sources.redhat.com References: <01c53cf6$Blat.v2.4$c2abfd80@zahav.net.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01c53cf6$Blat.v2.4$c2abfd80@zahav.net.il> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-04/txt/msg00050.txt.bz2 On Sat, Apr 09, 2005 at 02:23:55PM +0300, Eli Zaretskii wrote: > Can someone please tell me what is the advantage of using the vCont > request in the remote protocol? > > >From reading the sources, I see that remote.c:remote_resume uses an > alternative method via the `c' or `s' packets, but it isn't clear why > vCont is preferred. From various hints in the manual I vaguely > understand that this involves resuming different threads with > different conditions/signals, but the details are sketchy at best. In > particular, what GDB user-level commands are affected by availability > of vCont? > > I need this information to clarify the relevant manual sections. That's right - it's about thread support, both for the existing commands we have and some others that have been tossed about but never implemented. I apologize if it's unclear; I wrote that entry. The original way to control individual threads was to set the thread number using 'Hc', and then continue using one of the [CcSs] packets. Hc has options of "a specific thread", "all threads", or "any thread". This is only a small set of the possible resume actions; vCont is more thorough. One example of existing commands that could not be handled well by the old method is "set scheduler-locking" - in fact, its default setting, which is off - in combination with "thread". With scheduler locking off, the "step" command means "step this thread, but allow other threads to run freely while we do it". With it on, "step" means "step only the current thread". HcTID followed by s means the latter - we use this to step over a removed breakpoint. There's no clear way to send a step request which affects a particular thread, so the remote stub has to guess. Normally it guesses the last thread to run; normally that's right. Very frustrating when it's wrong. Another example that can be described by vCont but not by the existing commands is pausing a specific thread; there's no GDB interface for this today, but it's a reasonably intuitive operation. vCont can say "please continue this specific set of threads only". It's also marginally more efficient. A major bottleneck in the remote protocol is latency rather than bandwidth; we only have to ack one packet instead of two. And it reduces the statefulness of the protocol. -- Daniel Jacobowitz CodeSourcery, LLC