Re: RFC: MI output during program execution

Re: RFC: MI output during program execution

[Nick Roberts]

[moved from gdb-patches]

> Well I have no idea!  You didn't say what I broke.

	* linux-nat.c (linux_ops_saved): New.
	(super_mourn_inferior, kill_inferior, threaded, linux_nat_ops)
	(child_mourn_inferior, child_wait, linux_nat_create_inferior)
	(linux_nat_fetch_registers, linux_nat_store_registers)
	(linux_nat_child_post_startup_inferior, init_linux_nat_ops): Delete.
        ...
	(linux_target): Don't set to_wait, to_kill, or to_mourn_inferior.
        ...

The async code used a heavily changed version of child_wait (in linux-nat.c).

What does the new code use in place of this procedure?


Nick                                           http://www.inet.net.nz/~nickrob

Re: RFC: MI output during program execution

[Daniel Jacobowitz]

On Wed, Apr 05, 2006 at 10:03:02AM +1200, Nick Roberts wrote:
> 
> [moved from gdb-patches]
> 
> > Well I have no idea!  You didn't say what I broke.
> 
> 	* linux-nat.c (linux_ops_saved): New.
> 	(super_mourn_inferior, kill_inferior, threaded, linux_nat_ops)
> 	(child_mourn_inferior, child_wait, linux_nat_create_inferior)
> 	(linux_nat_fetch_registers, linux_nat_store_registers)
> 	(linux_nat_child_post_startup_inferior, init_linux_nat_ops): Delete.
>         ...
> 	(linux_target): Don't set to_wait, to_kill, or to_mourn_inferior.
>         ...
> 
> The async code used a heavily changed version of child_wait (in linux-nat.c).
> 
> What does the new code use in place of this procedure?

child_wait only ever worked for single-threaded executables.  Now
linux_nat_wait is used, for both single-threaded and multi-threaded
executables.

-- 
Daniel Jacobowitz
CodeSourcery

Re: RFC: MI output during program execution

[Nick Roberts]

 > > The async code used a heavily changed version of child_wait (in
 > > linux-nat.c).
 > > 
 > > What does the new code use in place of this procedure?
 > 
 > child_wait only ever worked for single-threaded executables.  Now
 > linux_nat_wait is used, for both single-threaded and multi-threaded
 > executables.

OK I follow that now and have moved the relevant async code from child_wait to
linux_nat_wait.  I've also re-instated the --async option so that --noasync
*should* run as on the trunk.

You said earlier that I'm free to create my own branch but since I've not done
that before for GDB I think its sensible to run this past you first.  Having
read the node Versions and Branches in the GDB Inernals manual I propose to:

1) Create a branchpoint of current HEAD for gdb+dejagnu:

   cvs rtag nickrob-200604026-branchpoint gdb+dejagnu

2) Create a branch from that branchpoint:

   cvs rtag -b  -r nickrob-200604026-branchpoint nickrob-200604026-branch \
                                                 gdb+dejagnu

3) Update my working directory to that branch:

   cvs update -r nickrob-200604026-branch

4) Add files called ChangeLog-async, README-async, TODO-async.

5) Modify version.in appropriately.

5) Commit my/Apple's changes.

6) Post those changes to gdb-patches.

7) Do regular merges with trunk:

   cvs update -j HEAD  (?)


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.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: RFC: MI output during program execution

[Daniel Jacobowitz]

On Wed, Apr 26, 2006 at 08:58:04AM +1200, Nick Roberts wrote:
> 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?

> 2) Create a branch from that branchpoint:
> 
>    cvs rtag -b  -r nickrob-200604026-branchpoint nickrob-200604026-branch \
>                                                  gdb+dejagnu

Right.

> 3) Update my working directory to that branch:
> 
>    cvs update -r nickrob-200604026-branch

Right.

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

> 5) Modify version.in appropriately.

Sure, if you want to clearly identify the branch - always a good idea.

> 5) Commit my/Apple's changes.

Right.

> 6) Post those changes to gdb-patches.

Right.

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

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

Great!

Your steps look fine; feel free.

-- 
Daniel Jacobowitz
CodeSourcery

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

[Nick Roberts]

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

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

[Daniel Jacobowitz]

On Fri, May 12, 2006 at 08:36:44PM +1200, Nick Roberts wrote:
> 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.

Right on both counts :-)

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

Don't worry about it too much.

> Actually thats quite a lot of data and probably not of general interest.  Shall
> I just post the ChangeLog?

I suppose; I can always grab the branch and diff it myself.

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

The trick is that you do everything relative to the tags, including
merges and other tags - nothing relative to HEAD.

  - Create new tag
  - Merge changes from last tag to new tag to branch.


-- 
Daniel Jacobowitz
CodeSourcery