From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5005 invoked by alias); 8 Mar 2008 20:36:59 -0000 Received: (qmail 4996 invoked by uid 22791); 8 Mar 2008 20:36:58 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 08 Mar 2008 20:36:32 +0000 Received: from kahikatea.snap.net.nz (252.31.255.123.static.snap.net.nz [123.255.31.252]) by viper.snap.net.nz (Postfix) with ESMTP id E8D393D912F; Sun, 9 Mar 2008 09:36:24 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 1000) id 1F8628FC6D; Sun, 9 Mar 2008 09:36:19 +1300 (NZDT) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18386.63679.965070.279756@kahikatea.snap.net.nz> Date: Sat, 08 Mar 2008 20:36:00 -0000 To: Vladimir Prus Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] Async mode fixes. In-Reply-To: <200803081158.40723.vladimir@codesourcery.com> References: <200803051027.29575.vladimir@codesourcery.com> <18385.48967.964309.898509@kahikatea.snap.net.nz> <200803081158.40723.vladimir@codesourcery.com> X-Mailer: VM 7.19 under Emacs 22.1.91.2 X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-03/txt/msg00072.txt.bz2 > Well, "target async" exists and has existed for a long time. I presume that > when it was added, it fully worked. However, as it was not routinely tested, > it has regressed to its current state. I think the asynchronous mode wasn't completed and that it only ever worked for remote targets. I'm starting to understand your patch now and see that your changes just make the asynchronous mode of remote targets work - and that's a sensible place to start. >... > > You don't appear to have changed that. This is where I have issue with the > > current `async' mode: it doesn't appear to use this continuation. > > Are you sure? I get the following with my patch: > > (gdb) > -interpreter-exec console continue > ~"Continuing.\n" > ^running > *stopped,reason="breakpoint-hit",bkptno="1",thread-id="1",..... I've not tested your patch, just looked at it. This doesn't work in the current code but I see now, as you say, that it's because target_executing is not reset to 0, not because the continuation isn't called. You say: > Yes. Nick patch has two bits: > 1. Linux native async mode (which Pedro is looking at as we speak) > 2. Core async mode changes. It really has three bits: 1. Core async mode changes. 2. Exec async mode changes. 3. Linux native async mode. I think the command "target async" is a bit misleading and it should really be called "target remote-async" (I'm not really suggesting changing it). My changes aren't just for Linux, but an exec target. I mean native debugging (I think) with just one implementation - linux. It sounds like I'm inflating what I've done but other native targets can presumably be adapted to make use of the changes in inf-ptrace.c, exec.c etc. If all targets could run asynchronously, then it seems that that mode should be specified at startup: gdb --async myprog in which case (gdb) target remote host:2222 would do what (gdb) target async host:2222 currently does and (gdb) run would run the native applications asynchronously. -- Nick http://www.inet.net.nz/~nickrob