From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27425 invoked by alias); 12 May 2006 08:37:31 -0000 Received: (qmail 27416 invoked by uid 22791); 12 May 2006 08:37:30 -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 May 2006 08:37:27 +0000 Received: from farnswood.snap.net.nz (p202-124-112-55.snap.net.nz [202.124.112.55]) by viper.snap.net.nz (Postfix) with ESMTP id CDE0E75651C; Fri, 12 May 2006 20:37:25 +1200 (NZST) Received: by farnswood.snap.net.nz (Postfix, from userid 500) id 7A6D7627ED; Fri, 12 May 2006 09:36:45 +0100 (BST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17508.18716.564160.93092@farnswood.snap.net.nz> Date: Fri, 12 May 2006 11:21:00 -0000 To: Daniel Jacobowitz Cc: gdb@sources.redhat.com Subject: New branch [was Re: RFC: MI output during program execution] In-Reply-To: <20060504150414.GE32605@nevyn.them.org> References: <17458.60694.135878.624750@farnswood.snap.net.nz> <20060404220637.GA12064@nevyn.them.org> <17486.36188.127822.347550@farnswood.snap.net.nz> <20060504150414.GE32605@nevyn.them.org> X-Mailer: VM 7.19 under Emacs 22.0.50.51 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-05/txt/msg00159.txt.bz2 > > 1) Create a branchpoint of current HEAD for gdb+dejagnu: > > > > cvs rtag nickrob-200604026-branchpoint gdb+dejagnu > > Right. You can just use the gdb module nowadays; the only difference > is that gdb+dejagnu will include tcl by accident. Expect and DejaGNU > aren't in the tree any more. Could I persuade you to update the > manual? I've done: cvs rtag nickrob-async-200604026-branchpoint gdb (the manual is on my TODO list). ... > > 4) Add files called ChangeLog-async, README-async, TODO-async. > > Right. I recommend putting these under the gdb subdirectory; otherwise > there's some trouble getting CVS to check them out by default because > of how we use modules. I've created README.async, TODO.async, PROBLEMS.async I've used ChangeLog for changes on the branch because I thought it would make commits easier (certainly from Emacs) but maybe that wasn't so clever as merges might be harder. > > 5) Modify version.in appropriately. > > Sure, if you want to clearly identify the branch - always a good idea. I've called it 6.4.50.20060512-nickrob-async. I took the date from the one I was given but because we're ahead of the rest of the world here in NZ, I had already used 20060513 for the branch name. Perhaps I should change it to 6.4.50.20060513-nickrob-async to be consistent? > > 5) Commit my/Apple's changes. > > Right. Done. > > 6) Post those changes to gdb-patches. > > Right. Actually thats quite a lot of data and probably not of general interest. Shall I just post the ChangeLog? > > 7) Do regular merges with trunk: > > > > cvs update -j HEAD (?) > > Well, it's more complicated than this. You need tags at mergepoints - > see the last bit of the chapter which mentions cvs up -j. It's a bit of > a pain. I can't get my head round mergepoints (what happens if someone elso commit after your tag but before your commit?) but I'll worry about that later. > > When I've got this far I'll also explain what the code does and what I > > would like it to do in the future (from README-async) on the gdb mailing > > list. See below. > Great! Thanks for your help! -- Nick http://www.inet.net.nz/~nickrob README.async This branch is an attempt to get GDB to work asynchronously (whatever that might mean). I have started this by copying some changes from Apple's version (CVS as of Sept 5 2005 and covered by GPL) to get some of the funtionality that I'm looking for (and because I couldn't do it on my own!). It uses pthreads which Daniel Jacobowitz dislikes and thinks that it should be done in one process. Where I don't really understand the code changes, I have put "Make asynchronous." and somtimes "(copied verbatim)" in the ChangeLog. 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" its identical. To help integration with HEAD I've re-instated the --async option so that --noasync (the default) *should* run as on the trunk. Bugs/Problems are in PROBLEMS.async