Re: async patch (no. 4)

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

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