Re: async patch (no. 4)

Nick Roberts
2007-01-12T22:24:23Z

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