From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27131 invoked by alias); 18 Dec 2008 16:50:15 -0000 Received: (qmail 27123 invoked by uid 22791); 18 Dec 2008 16:50:13 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 18 Dec 2008 16:49:38 +0000 Received: (qmail 3190 invoked from network); 18 Dec 2008 16:49:36 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 18 Dec 2008 16:49:36 -0000 From: Pedro Alves To: gdb@sourceware.org Subject: Re: Async mode and setting breakpoints Date: Thu, 18 Dec 2008 16:50:00 -0000 User-Agent: KMail/1.9.10 Cc: "Marc Khouzam" References: <6D19CA8D71C89C43A057926FE0D4ADAA06AA14F6@ecamlmw720.eamcs.ericsson.se> In-Reply-To: <6D19CA8D71C89C43A057926FE0D4ADAA06AA14F6@ecamlmw720.eamcs.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200812181649.37699.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-12/txt/msg00078.txt.bz2 Hi Marc, On Thursday 18 December 2008 15:41:33, Marc Khouzam wrote: > I'm investigating the value of using async mode without non-stop > to decide if I should use it whenever possible for DSF-GDB. > > The main advantage I was seeking was to be able to set a breakpoint > while the target was running. It does not work though. > I'm guessing that while the inferior is running, it is not possible > for GDB to plant the breakpoint (although the bp command is accepted > without complaint). I guess I still have to interrupt the inferior, > set the bp, and resume, even in async mode? Short answer, yes, in all async capable targets currently supported by GDB (that's linux native and remote). This is target dependent, on two levels. On native linux, inserting a breakpoint in all-stop,async will fail when the target is running, because it isn't possible to patch memory when the target is running. GDB could be momentarily stopping an LWP of the inferior process to do this, but it isn't. There are some threads in the archives about this. The remote target is a bit more complicated. Against remote targets, even if the OS allows patching memory or inserting breakpoints to running processes, due to the design of the years old standard all-stop remote protocol, it is not possible to issue any command to the remote while the target is running. Inserting a breakpoint requires talking to the remote side. In more detail, after GDB issues a resume request (vCont, s, c, etc.), the remote side will not be ready for any other packet. GDB can only send an interrupt request (which is really an out of band request) in this state, or wait for a stop reply. If GDB did send another packet in this state, both the stub and GDB would end up confused. To prevent this, if this condition is detected, GDB errors out with "Cannot execute this command while the target is running." (remote.c:putpkt_binary). This means that in all-stop + async + remote, any GDB command that tries to talk to the remote side while the remote is running will error out. Any command that *doesn't* talk to the remote side will still work. The non-stop version of the remote protocol removed this protocol level limitation, mostly by making stop replies asynchronous, so the stub can accept more commands while the target is running. It is still dependent on the stub/OS if it is possible to insert breakpoints or patch memory while the target is running though. Same in native non-stop. -- Pedro Alves