From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30855 invoked by alias); 12 Jan 2007 22:24:23 -0000 Received: (qmail 30841 invoked by uid 22791); 12 Jan 2007 22:24:22 -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; Fri, 12 Jan 2007 22:24:16 +0000 Received: from kahikatea.snap.net.nz (p202-124-125-80.snap.net.nz [202.124.125.80]) by viper.snap.net.nz (Postfix) with ESMTP id 9A77D3D8367; Sat, 13 Jan 2007 11:24:08 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 500) id 950A64F705; Sat, 13 Jan 2007 11:24:06 +1300 (NZDT) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17832.2690.298735.867020@kahikatea.snap.net.nz> Date: Fri, 12 Jan 2007 22:24:00 -0000 To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: async patch (no. 4) In-Reply-To: <20070112183120.GB30005@nevyn.them.org> References: <17720.29835.230422.776965@kahikatea.snap.net.nz> <20070112183120.GB30005@nevyn.them.org> X-Mailer: VM 7.19 under Emacs 22.0.92.8 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: 2007-01/txt/msg00323.txt.bz2 > I've started looking at this. I suspect I've asked you this before; if > so, I apologize. But could you give me the big picture on what is > supposed to be different with this patch applied - what's the goal, and > should it be the default eventually? No matter how I stare at it, I > can't figure out what's going on. To get the async behaviour you need to start GDB with the --async option. In my branch I have a file called README.async which explains more (see below) > A problem I run into often at work is that when you try to merge > another person's work, you often don't know how every bit of it works. > But in order to review it, you've really got to figure out each > line of it. I try to read every line of my patch and ask myself > why that line is right / necessary. You're not looking at the last patch, which is smaller, that I sent: Re: [PATCH] PR mi/2077 "set edit off" breaks MI" (Tue, 21 Nov 2006 11:20:41 +1300) You> We've branched; you have a patch ready; let's get it going! I'd be You> glad to see this merged. I'm afraid I really haven't looked at what You> you have so far; could you post a current patch that I can experiment You> with? Me> I'm attaching it below.... It's a much smaller change than I started with in the async branch and I understand more lines than I did then. Clearly when it comes to committing the patch I/we need to understand each line but for now I left in things that I thought were necessary. > There's things in this patch that I definitely don't want to merge > without understanding them. For instance, the #if 0's in interp_set, > and this comment: > > + /* APPLE LOCAL: I don't think we want to clear the parent interpreter's > + The parent interpreter may want to be able to snoop on the child > + interpreter through them. */ > > I thought the interpreters were supposed to be independent, which makes > that comment suspicious, and I don't see what it applies to either. This is still in the latest patch. I'm unable to currently answer this question. > Oh, and I noticed that there's nothing here that needs the new argument > to deprecated_command_loop_hook. I'll remove it if it's not needed. -- Nick http://www.inet.net.nz/~nickrob (edited README.async) The initial changes are directed at the output of the asynchronous commands such as run, continue, next, finish etc. These are implemented through mi_execute_async_cli_command and for asynchronus operation require mi_exec_async_cli_cmd_continuation to be called through fetch_inferior event. Currently -exec-next and next generate different output because the asynchronous output is faked: (gdb) -exec-next ^running (gdb) *stopped,reason="end-stepping-range",thread-id="0",frame={addr="0x0804857f",func="main",args=[],file="myprog.c",fullname="/home/nickrob/myprog.c",line="69"} (gdb) n &"n\n" ~"70\t int n1 = 7, n2 = 8, n3 = 9;\n" ^done (gdb) With these changes the output is the same: -exec-next ^running (gdb) *stopped,reason="end-stepping-range",thread-id="0",frame={addr="0x0804857f",func="main",args=[],file="myprog.c",fullname="/home/nickrob/myprog.c",line="69"} (gdb) n &"n\n" ^running ^done (gdb) *stopped,reason="end-stepping-range",thread-id="0",frame={addr="0x080485bb",func="main",args=[],file="myprog.c",fullname="/home/nickrob/myprog.c",line="70"} (gdb) (actually it generates an extra &"n\n" and ^done but with "-interpreter-exec console" it's identical. To enter a GDB command while the target is running GDB needs a separate terminal to the inferior. Currently only a few CLI commands can be entered e.g pwd see top.c. Most CLI commands report: Cannot execute this command while the target is running. and all MI commands apart from -exec-interrupt (see mi-main.c) report: Cannot execute command interpreter-exec while target running but this can easily be changed. I've re-instated the --async option so that --noasync (the default) *should* run as before. To run testsuite with asynchronous event loop put the line: set GDBFLAGS "--async" at the bottom of site.exp.