New branch [was Re: RFC: MI output during program execution]

[Nick Roberts <nickrob@snap.net.nz>]

 > > 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