Re: RFC: MI output during program execution

Re: RFC: MI output during program execution

[Nick Roberts]

I've read most of the discussion through the archives.  I find the idea of
notifying the frontend about all changes of state a laudable goal but
currently too difficult (for me).  However, I would still like GDB to
convey to the frontend when the inferior is running.  Jim's point about the
"define" command shoots down the patch that I sent earlier so I would like to
suggest another approach.  I would like to take the "^running" and "*stopped"
tokens out of mi-main.c and put them in infrun.c where annotate_starting and
annotate_stopped are respectively called.  This seems more in line with the
idea of notification and works when I test it natively on GNU/Linux.  I am
sure that it will fail somewhere else (remote targets?) otherwise this
approach would have surely been used in the first place.

With this method user-defined commands work as for simple GDB commands.  CLI
commands don't give full MI output but information like the current line can
be obtained by polling with -stack-info-frame.

-exec-next
^running
(gdb) 
*stopped,reason="end-stepping-range",thread-id="0",frame={addr="0x080484ef",func="main",args=[{name="argc",value="1"},{name="argv",value="0xbffff794"}],file="myprog.c",fullname="/home/nick/myprog.c",line="46"}
(gdb) 
n
&"n\n"
^running
(gdb) 
~"47\t  int n1=7, n2=8, n3=9;\n"
*stopped
^done
(gdb) 

Using strcmp (interpreter_p, "mi") and not strncmp (interpreter_p, "mi", 2)
means that this should only change behaviour for the current mi level.

WDYT?

Nick

*** infrun.c.~1.203~	2005-08-15 10:38:14.000000000 +1200
--- infrun.c	2005-08-15 10:42:50.000000000 +1200
***************
*** 49,54 ****
--- 49,57 ----
  
  #include "gdb_assert.h"
  #include "mi/mi-common.h"
+ #include "mi/mi-out.h"
+ 
+ extern struct ui_file *raw_stdout;
  
  /* Prototypes for local functions */
  
*************** proceed (CORE_ADDR addr, enum target_sig
*** 785,790 ****
--- 788,799 ----
  
    annotate_starting ();
  
+   if (strcmp (interpreter_p, "mi") == 0)
+     {
+       fputs_unfiltered ("^running\n", raw_stdout);
+       fputs_unfiltered ("(gdb) \n", raw_stdout);
+     }
+ 
    /* Make sure that output from GDB appears before output from the
       inferior.  */
    gdb_flush (gdb_stdout);
*************** Further execution is probably impossible
*** 3136,3141 ****
--- 3145,3158 ----
  done:
    annotate_stopped ();
    observer_notify_normal_stop (stop_bpstat);
+   if ((strcmp (interpreter_p, "mi") == 0) || (ui_out_is_mi_like_p (uiout)))
+       fputs_unfiltered ("*stopped", raw_stdout);
+   if (ui_out_is_mi_like_p (uiout))
+     {
+       mi_out_put (uiout, raw_stdout);
+       mi_out_rewind (uiout);
+     }
+   fputs_unfiltered ("\n", raw_stdout);
  }
  
  static int


*** mi/mi-main.c.~1.80.~	2005-06-14 09:18:08.000000000 +1200
--- mi/mi-main.c	2005-08-14 20:10:44.000000000 +1200
*************** mi_execute_async_cli_command (char *mi, 
*** 1306,1313 ****
           command. */
        if (last_async_command)
  	fputs_unfiltered (last_async_command, raw_stdout);
-       fputs_unfiltered ("^running\n", raw_stdout);
-       fputs_unfiltered ("(gdb) \n", raw_stdout);
        gdb_flush (raw_stdout);
      }
    else
--- 1306,1311 ----
*************** mi_execute_async_cli_command (char *mi, 
*** 1318,1324 ****
           run command to the target. */
        if (last_async_command)
  	fputs_unfiltered (last_async_command, raw_stdout);
-       fputs_unfiltered ("^running\n", raw_stdout);
      }
  
    execute_command ( /*ui */ run, 0 /*from_tty */ );
--- 1316,1321 ----
*************** mi_execute_async_cli_command (char *mi, 
*** 1332,1341 ****
           the stopped message. */
        if (last_async_command)
  	fputs_unfiltered (last_async_command, raw_stdout);
-       fputs_unfiltered ("*stopped", raw_stdout);
-       mi_out_put (uiout, raw_stdout);
-       mi_out_rewind (uiout);
-       fputs_unfiltered ("\n", raw_stdout);
        return MI_CMD_QUIET;
      }
    return MI_CMD_DONE;
--- 1329,1334 ----

Re: RFC: MI output during program execution

[Daniel Jacobowitz]

On Mon, Aug 15, 2005 at 10:54:44AM +1200, Nick Roberts wrote:
> 
> I've read most of the discussion through the archives.  I find the idea of
> notifying the frontend about all changes of state a laudable goal but
> currently too difficult (for me).  However, I would still like GDB to
> convey to the frontend when the inferior is running.  Jim's point about the
> "define" command shoots down the patch that I sent earlier so I would like to
> suggest another approach.  I would like to take the "^running" and "*stopped"
> tokens out of mi-main.c and put them in infrun.c where annotate_starting and
> annotate_stopped are respectively called.  This seems more in line with the
> idea of notification and works when I test it natively on GNU/Linux.  I am
> sure that it will fail somewhere else (remote targets?) otherwise this
> approach would have surely been used in the first place.
> 
> With this method user-defined commands work as for simple GDB commands.  CLI
> commands don't give full MI output but information like the current line can
> be obtained by polling with -stack-info-frame.
> 
> -exec-next
> ^running
> (gdb) 
> *stopped,reason="end-stepping-range",thread-id="0",frame={addr="0x080484ef",func="main",args=[{name="argc",value="1"},{name="argv",value="0xbffff794"}],file="myprog.c",fullname="/home/nick/myprog.c",line="46"}
> (gdb) 
> n
> &"n\n"
> ^running
> (gdb) 
> ~"47\t  int n1=7, n2=8, n3=9;\n"
> *stopped
> ^done
> (gdb) 
> 
> Using strcmp (interpreter_p, "mi") and not strncmp (interpreter_p, "mi", 2)
> means that this should only change behaviour for the current mi level.

Checking the name of the MI interpreter seems inelegant.  It'll break
this when we transition from MI2 to MI3 as the stable version for
instance.  Maybe there's a way to make mi_version usable outside of
mi/*.

Forcing this to raw_stdout is also not OK, since my whole point was to
pass this information to the interpreter so that it can distribute it
to clients appropriately - they may not be on stdout.  I realize that's
what the MI layer previously did, but I don't get a good taste in my
mouth from bypassing the MI output layer this way.

The hooks we were talking about were primarily for things like the
breakpoint list and thread list.  The ^running response is touchier.
^running is a result record, not an async record.  It has to be the
result of a command.  Bob's our expert on this, but I'd think that this
change could break the grammar.  There's probably a way to get this to
happen when the resulting prompt does not signify that another command
may be accepted now.

Certainly it makes verifying from the source that we obey the grammar
much more difficult, by moving bits of the MI implementation into
infrun.  That's enough reason for it not to have been done this way in
the first place - it's harder to maintain.

Also, Bob said he was willing to work on doing this correctly.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: RFC: MI output during program execution

[Nick Roberts]

 > > Using strcmp (interpreter_p, "mi") and not strncmp (interpreter_p, "mi", 2)
 > > means that this should only change behaviour for the current mi level.
 > 
 > Checking the name of the MI interpreter seems inelegant.  It'll break
 > this when we transition from MI2 to MI3 as the stable version for
 > instance.  Maybe there's a way to make mi_version usable outside of
 > mi/*.

If the change proves to a good one (which seems unlikely now) then it could
possibly be used for all versions.

 > Forcing this to raw_stdout is also not OK, since my whole point was to
 > pass this information to the interpreter so that it can distribute it
 > to clients appropriately - they may not be on stdout.  I realize that's
 > what the MI layer previously did, but I don't get a good taste in my
 > mouth from bypassing the MI output layer this way.

You presumably mean what the MI layer _currently does_.  Using raw_stdout
doesn't improve things but it doesn't make them any worse.

 > The hooks we were talking about were primarily for things like the
 > breakpoint list and thread list.  The ^running response is touchier.
 > ^running is a result record, not an async record.  It has to be the
 > result of a command.  

It is classed as a result record in MI but presumably its an asynchronous
process.  Perhaps it should be *running, just as it is *stopped.  Treating it
as a result record means that new commands which run the inferior must
also call mi_execute_async_cli_command or they won't output ^running.  Putting
it in proceed ensures this automatically.

 >                      Bob's our expert on this, but I'd think that this
 > change could break the grammar.  There's probably a way to get this to
 > happen when the resulting prompt does not signify that another command
 > may be accepted now.
 > 
 > Certainly it makes verifying from the source that we obey the grammar
 > much more difficult, by moving bits of the MI implementation into
 > infrun.  That's enough reason for it not to have been done this way in
 > the first place - it's harder to maintain.

I will look at making to more modular.  You have said:

DJ> What I'd like to see is a way to keep multiple interpreters open at the
DJ> same time.Then, have one of them accepting input at a time, and receiving
DJ> informative output, but all of them receiving some kinds of output.

This presumably requires the code that generates MI output to be moved
outside MI specific code.

 > Also, Bob said he was willing to work on doing this correctly.

I'm lost.  I'm not sure what correctly means in this case.  I would like
to get MI-like output (specifically about whether the execution is running
or not) from CLI commands.  Is Bob offering to do this?

Nick

Re: RFC: MI output during program execution

[Bob Rossi]

>  > Also, Bob said he was willing to work on doing this correctly.
> 
> I'm lost.  I'm not sure what correctly means in this case.  I would like
> to get MI-like output (specifically about whether the execution is running
> or not) from CLI commands.  Is Bob offering to do this?

Hi Nick,

What I offered to work on (because you mentioned you didn't have time),
is to improve the MI interface, by changing GDB's internals to alert
other parts of GDB (MI, maybe annotate=2,3) when certain conditions or
states have changed. For instance, breakpoints, frame's, threads, or
inferior state.

By doing this, the MI layer can then check to see what has changed after
each command is run, including -interpreter-exec console commands. The
MI layer can then issue data to the FE depending on what has changed,
and potentially what the FE requested for changes.

This might require changing the MI output syntax to add a new section
for changes like above. I'm not sure about this yet.

Does this proposed solution sound reasonable to you? Will this solve all
the needs that you have? To be honest, CGDB also won't work without
these changes. However, with theses changes, MI might be getting close
to being very usable, thus, deprecating annotations. Do you agree?

To be realist, I expect these changes to take several months. Especially
since Mark Kettenis asked that all the deprecated functions be removed
first. Hopefully the time won't be an issue.

Thanks,
Bob Rossi

Re: RFC: MI output during program execution

[Nick Roberts]

 > What I offered to work on (because you mentioned you didn't have time),
 > is to improve the MI interface, by changing GDB's internals to alert
 > other parts of GDB (MI, maybe annotate=2,3) when certain conditions or
 > states have changed. For instance, breakpoints, frame's, threads, or
 > inferior state.

I wasn't just a question of time, I don't currently have enough understanding
of the code as a whole.  I do know that there will be problems with threads,
for example.  Previous discussion on the mailing list has shown that GDB loses
track of the selected frame when the thread is changed back and forth.  Also
variable objects don't record the thread for which they were created.

 > By doing this, the MI layer can then check to see what has changed after
 > each command is run, including -interpreter-exec console commands. The
 > MI layer can then issue data to the FE depending on what has changed,
 > and potentially what the FE requested for changes.
 > 
 > This might require changing the MI output syntax to add a new section
 > for changes like above. I'm not sure about this yet.
 > 
 > Does this proposed solution sound reasonable to you? Will this solve all
 > the needs that you have? To be honest, CGDB also won't work without
 > these changes. However, with theses changes, MI might be getting close
 > to being very usable, thus, deprecating annotations. Do you agree?

I poll GDB to get the state after every command.  This might be slower but
it's generally workable.  On the other hand, I can't find out if the inferior
is running or not when a CLI command is executed.  I don't think that your
proposed changes will solve this problem.

 > To be realist, I expect these changes to take several months. Especially
 > since Mark Kettenis asked that all the deprecated functions be removed
 > first. Hopefully the time won't be an issue.

More like several years I would think!  The location of the deprecated
functions in the code tells you where notification should take place.  I would
remove these once you have your code working.  This presumably also provides a
fallback position.

Nick

Re: RFC: MI output during program execution

[Daniel Jacobowitz]

On Mon, Aug 15, 2005 at 04:28:07PM +1200, Nick Roberts wrote:
>  > The hooks we were talking about were primarily for things like the
>  > breakpoint list and thread list.  The ^running response is touchier.
>  > ^running is a result record, not an async record.  It has to be the
>  > result of a command.  
> 
> It is classed as a result record in MI but presumably its an asynchronous
> process.  Perhaps it should be *running, just as it is *stopped.  Treating it

Yeah - I'm beginning to think that we should use this:

(gdb)
-exec-continue
*running
^done
(gdb)

Instead of the current:

(gdb)
-exec-continue
^running
(gdb)

It'd definitely have to be mi3 only, though!  This would be a pretty
big change that frontends would have to adapt to.

The asymmetry between ^running and *stopped will bite us here.  For
instance, for a CLI command, I'd want roughly:

(gdb)
-interpreter-exec console "continue"
*running
^done
(gdb)

Anyway, food for thought.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: RFC: MI output during program execution

[Bob Rossi]

On Mon, Aug 15, 2005 at 08:33:11PM -0400, Daniel Jacobowitz wrote:
> On Mon, Aug 15, 2005 at 04:28:07PM +1200, Nick Roberts wrote:
> >  > The hooks we were talking about were primarily for things like the
> >  > breakpoint list and thread list.  The ^running response is touchier.
> >  > ^running is a result record, not an async record.  It has to be the
> >  > result of a command.  
> > 
> > It is classed as a result record in MI but presumably its an asynchronous
> > process.  Perhaps it should be *running, just as it is *stopped.  Treating it
> 
> Yeah - I'm beginning to think that we should use this:
> 
> (gdb)
> -exec-continue
> *running
> ^done
> (gdb)
> 
> Instead of the current:
> 
> (gdb)
> -exec-continue
> ^running
> (gdb)

Agreed.

> It'd definitely have to be mi3 only, though!  This would be a pretty
> big change that frontends would have to adapt to.
> 
> The asymmetry between ^running and *stopped will bite us here.  For
> instance, for a CLI command, I'd want roughly:
> 
> (gdb)
> -interpreter-exec console "continue"
> *running
> ^done
> (gdb)

Agreed.

Bob Rossi

Re: RFC: MI output during program execution

[Daniel Jacobowitz]

On Wed, Mar 29, 2006 at 10:16:40AM +1200, Nick Roberts wrote:
>  > > I never created a branch in the repository but kept merging changes in the
>  > > repository to my/Apple's changes.
>  > 
>  > Unfortunately this means no one else can try what you've got...
> 
> The reality is no-one will currently want to and it seemed easier to merge
> locally.

It works both ways.  I'm not going to take a look at it while it's
sitting on your local drive.

> Incidentally if GDB changes version control, I think a distributed
> system like Arch would make keeping local branches easier, if thats an
> advantage.  Now with CVS I have to wade through filenames starting with .#...

I think SVN is the most likely change, and SVK works fine for this - I
do that already with GCC.  I want to migrate GDB, I just haven't had
time to work through the technical hurdles so I haven't started trying
to persuade folks it's a good idea.

-- 
Daniel Jacobowitz
CodeSourcery

Re: RFC: MI output during program execution

[Nick Roberts]

 > > I never created a branch in the repository but kept merging changes in the
 > > repository to my/Apple's changes.
 > 
 > Unfortunately this means no one else can try what you've got...

The reality is no-one will currently want to and it seemed easier to merge
locally.  Incidentally if GDB changes version control, I think a distributed
system like Arch would make keeping local branches easier, if thats an
advantage.  Now with CVS I have to wade through filenames starting with .#...

 > > This worked OK until:  
 > > 
 > > 2006-03-24  Daniel Jacobowitz  <dan@codesourcery.com>
 > > 
 > > 	* 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.
 > > 	...
 > > 
 > > Have you any one liners that might help me understand these changes and
 > > what I can do to get GDB to work asynchronously again (at least for
 > > Linux).
 > 
 > Well, I have no idea!  You didn't say what broke.  It replaces the two
 > Linux native vectors with one combined vector that works for both.

I was just clutching at straws.  I don't know what broke, so I'll have to go
through the changes one by one.


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

Re: RFC: MI output during program execution

[Daniel Jacobowitz]

On Tue, Mar 28, 2006 at 09:54:31AM +1200, Nick Roberts wrote:
>  DJ> Sorry, miscommunication.  You don't need approval to create a branch;
>  DJ> go right ahead.
> 
> I never created a branch in the repository but kept merging changes in the
> repository to my/Apple's changes.

Unfortunately this means no one else can try what you've got...

> This worked OK until:  
> 
> 2006-03-24  Daniel Jacobowitz  <dan@codesourcery.com>
> 
> 	* 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.
> 	...
> 
> Have you any one liners that might help me understand these changes and what
> I can do to get GDB to work asynchronously again (at least for Linux).

Well, I have no idea!  You didn't say what broke.  It replaces the two
Linux native vectors with one combined vector that works for both.

> Does this patch relate to (3 Oct 2005):
> 
>  DJ> I violently dislike the idea of linking gdb with pthreads.  I'm
>  DJ> confident that we can get the benefits without that, however.  I've got
>  DJ> this patch sitting in my queue of things to play with.

Not at all.  This is about debugging threaded applications, not about a
threaded or non-threaded GDB.

-- 
Daniel Jacobowitz
CodeSourcery

Re: RFC: MI output during program execution

[Nick Roberts]

Re getting GDB to work asynchronously (19 Sep 2005):

Me> I now have something that works for GNU/Linux (probably under limited
Me> conditions).  With MI it now picks up mi_exec_async_cli_cmd_continuation to
Me> print the *stopped record, even with CLI commands like "run":



 Me> > Can I go ahead and create a branch?  I have a version of gdb-mi.el that
 Me> > works quite well with these changes.  I am (naively?) hoping that there
 Me> > will be some interest after Emacs 22 is released?
 > 
 DJ> Sorry, miscommunication.  You don't need approval to create a branch;
 DJ> go right ahead.

I never created a branch in the repository but kept merging changes in the
repository to my/Apple's changes.

This worked OK until:  

2006-03-24  Daniel Jacobowitz  <dan@codesourcery.com>

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

Have you any one liners that might help me understand these changes and what
I can do to get GDB to work asynchronously again (at least for Linux).

Does this patch relate to (3 Oct 2005):

 DJ> I violently dislike the idea of linking gdb with pthreads.  I'm
 DJ> confident that we can get the benefits without that, however.  I've got
 DJ> this patch sitting in my queue of things to play with.


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

Re: RFC: MI output during program execution

[Daniel Jacobowitz]

On Mon, Oct 03, 2005 at 02:37:56PM -0700, Stan Shebs wrote:
> Remote async can do it (more-or-less) portably because both the user
> and target interaction happen through file descriptors, and the usual
> API supports multiplexing. Darwin is problematic because you have
> to get some data from events and the like that only have blocking
> calls to monitor, so you need a thread per blocking syscall.

If Darwin's really got no non-blocking way to do this, then it'll need
either threading, or a helper process which handles the blocking events
and feeds them back to a file descriptor.  Threading is probably
easier, I agree.

> >This is a little more complicated to design, however, it's got less
> >complexity at runtime.  I've spent enough of my life using GDB on
> >systems where pthreads didn't work that I don't want to make GDB
> >dependent on them.
> >
> Ideally you'd push the thread/multiplex decision down into target code,
> but this would be a semi-ambitious rework to event-loop.c. It might
> not matter though, if Darwin (and other configs maybe) can keep using
> their own thread-hell code, while something like Linux can assume file
> descriptors for inferior monitoring and thus use the general mechanism.

I can't see any immediate reason why the upper levels need to know
about this.  I still need to take a look at Nick's patch, though.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: RFC: MI output during program execution

[Daniel Jacobowitz]

On Mon, Oct 03, 2005 at 02:50:27PM -0700, Jim Ingham wrote:
> This isn't just Mac OS X.  Any ptrace based system that wants to  
> write a real async target is going to have to spawn a thread  
> somewhere to do it, since ptrace is a blocking call.

That's wrong.  First of all, ptrace never blocks.  Second of all,
ptrace returns events through wait4, which generates SIGCHLD.  All very
amenable to handling in select().

> This isn't so bad, though.  If the platform doesn't have a reliable  
> pthreads implementation, it won't get a flakey gdb, rather, it just  
> won't get an async native target.

Well, I'd rather only have one set of targets than maintain both...
if we can make the target loop fully asynchronous, then we should do
that.  Otherwise one code path is absolutely promised to bit-rot.

As an aside, it's not so much a question of a reliable pthreads
implementation, as being able to use GDB to debug the pthreads
implementation.


-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: RFC: MI output during program execution

[Jim Ingham]

This isn't just Mac OS X.  Any ptrace based system that wants to  
write a real async target is going to have to spawn a thread  
somewhere to do it, since ptrace is a blocking call.

This isn't so bad, though.  If the platform doesn't have a reliable  
pthreads implementation, it won't get a flakey gdb, rather, it just  
won't get an async native target.

Jim



On Oct 3, 2005, at 2:37 PM, Stan Shebs wrote:

> Daniel Jacobowitz wrote:
>
>
>> On Tue, Oct 04, 2005 at 08:29:32AM +1300, Nick Roberts wrote:
>>
>>
>>> Daniel Jacobowitz writes:
>>> > Sorry, miscommunication.  You don't need approval to create a  
>>> branch;
>>> > go right ahead.
>>>
>>> OK. Thanks.
>>>
>>> > I violently dislike the idea of linking gdb with pthreads.  I'm
>>> > confident that we can get the benefits without that, however.   
>>> I've got
>>> > this patch sitting in my queue of things to play with.
>>>
>>> I know this will sound stupid but what is the alternative? Using  
>>> fork?
>>>
>>>
>>
>> Doing it "asynchronously" through the GDB event loop, which is I
>> believe the same way we handle remote async targets.  All in one
>> process.
>>
>>
> Remote async can do it (more-or-less) portably because both the user
> and target interaction happen through file descriptors, and the usual
> API supports multiplexing. Darwin is problematic because you have
> to get some data from events and the like that only have blocking
> calls to monitor, so you need a thread per blocking syscall.
>
>
>>
>> This is a little more complicated to design, however, it's got less
>> complexity at runtime.  I've spent enough of my life using GDB on
>> systems where pthreads didn't work that I don't want to make GDB
>> dependent on them.
>>
>>
> Ideally you'd push the thread/multiplex decision down into target  
> code,
> but this would be a semi-ambitious rework to event-loop.c. It might
> not matter though, if Darwin (and other configs maybe) can keep using
> their own thread-hell code, while something like Linux can assume file
> descriptors for inferior monitoring and thus use the general  
> mechanism.
>
> Stan
>
>

Re: RFC: MI output during program execution

[Stan Shebs]

Daniel Jacobowitz wrote:

>On Tue, Oct 04, 2005 at 08:29:32AM +1300, Nick Roberts wrote:
>
>>Daniel Jacobowitz writes:
>> > Sorry, miscommunication.  You don't need approval to create a branch;
>> > go right ahead.
>>
>>OK. Thanks.
>>
>> > I violently dislike the idea of linking gdb with pthreads.  I'm
>> > confident that we can get the benefits without that, however.  I've got
>> > this patch sitting in my queue of things to play with.
>>
>>I know this will sound stupid but what is the alternative? Using fork?
>>
>
>Doing it "asynchronously" through the GDB event loop, which is I
>believe the same way we handle remote async targets.  All in one
>process.
>
Remote async can do it (more-or-less) portably because both the user
and target interaction happen through file descriptors, and the usual
API supports multiplexing. Darwin is problematic because you have
to get some data from events and the like that only have blocking
calls to monitor, so you need a thread per blocking syscall.

>
>This is a little more complicated to design, however, it's got less
>complexity at runtime.  I've spent enough of my life using GDB on
>systems where pthreads didn't work that I don't want to make GDB
>dependent on them.
>
Ideally you'd push the thread/multiplex decision down into target code,
but this would be a semi-ambitious rework to event-loop.c. It might
not matter though, if Darwin (and other configs maybe) can keep using
their own thread-hell code, while something like Linux can assume file
descriptors for inferior monitoring and thus use the general mechanism.

Stan

Re: RFC: MI output during program execution

[Daniel Jacobowitz]

On Tue, Oct 04, 2005 at 08:29:32AM +1300, Nick Roberts wrote:
> Daniel Jacobowitz writes:
>  > Sorry, miscommunication.  You don't need approval to create a branch;
>  > go right ahead.
> 
> OK. Thanks.
> 
>  > I violently dislike the idea of linking gdb with pthreads.  I'm
>  > confident that we can get the benefits without that, however.  I've got
>  > this patch sitting in my queue of things to play with.
> 
> I know this will sound stupid but what is the alternative? Using fork?

Doing it "asynchronously" through the GDB event loop, which is I
believe the same way we handle remote async targets.  All in one
process.

This is a little more complicated to design, however, it's got less
complexity at runtime.  I've spent enough of my life using GDB on
systems where pthreads didn't work that I don't want to make GDB
dependent on them.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: RFC: MI output during program execution

[Nick Roberts]

Daniel Jacobowitz writes:
 > Sorry, miscommunication.  You don't need approval to create a branch;
 > go right ahead.

OK. Thanks.

 > I violently dislike the idea of linking gdb with pthreads.  I'm
 > confident that we can get the benefits without that, however.  I've got
 > this patch sitting in my queue of things to play with.

I know this will sound stupid but what is the alternative? Using fork?

Nick

Re: RFC: MI output during program execution

[Daniel Jacobowitz]

On Mon, Oct 03, 2005 at 03:20:59PM +1300, Nick Roberts wrote:
> Nick Roberts writes:
>  > If I am given approval to commit these changes to a branch then I will create
>  > ChangeLog entries (attributed to Apple).
> 
> Can I go ahead and create a branch?  I have a version of gdb-mi.el that works
> quite well with these changes.  I am (naively?) hoping that there will be
> some interest after Emacs 22 is released?

Sorry, miscommunication.  You don't need approval to create a branch;
go right ahead.

I violently dislike the idea of linking gdb with pthreads.  I'm
confident that we can get the benefits without that, however.  I've got
this patch sitting in my queue of things to play with.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: RFC: MI output during program execution

[Nick Roberts]

Nick Roberts writes:
 > If I am given approval to commit these changes to a branch then I will create
 > ChangeLog entries (attributed to Apple).

Can I go ahead and create a branch?  I have a version of gdb-mi.el that works
quite well with these changes.  I am (naively?) hoping that there will be
some interest after Emacs 22 is released?

Nick

Re: RFC: MI output during program execution

[Daniel Jacobowitz]

On Tue, Sep 20, 2005 at 10:17:49AM +1200, Nick Roberts wrote:
> 
> While people are talking kernels, I should say that my patch works for
> 2.6.9-1.667 (Fedora 3) but not 2.4.19-16mdkcustom (Mandrake 9).  Something
> to do with waitpid.

Not surprising.  This probably happens because you're waiting for the
inferior from a thread; that is not portable.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: RFC: MI output during program execution

[Nick Roberts]

While people are talking kernels, I should say that my patch works for
2.6.9-1.667 (Fedora 3) but not 2.4.19-16mdkcustom (Mandrake 9).  Something
to do with waitpid.

Nick

Re: RFC: MI output during program execution

[Nick Roberts]

[-- Attachment #1: message body text --]
[-- Type: text/plain, Size: 1148 bytes --]

Daniel Jacobowitz writes:
 > The rules for a branch are, generally, up to the branch owner.  The
 > only one I'll insist on is that copyright assignments be handled in the
 > same way as for HEAD, which is not a problem here.

You mean if someone else contributes a patch?  My changes are covered by the
assignment that I have already made for GDB.  Apple's changes are presumably
covered similarly.

 >                                                          See:
 > 
 >   http://sources.redhat.com/gdb/current/onlinedocs/gdbint_15.html#SEC133
 > (which are mostly guidelines rather than rules).  So, you can create a
 > branch if you'd like.

OK.  Thats helpful

 > I took a quick look at the changes, but couldn't make heads or tails
 > out of what was going on.  Also, I think the diff is corrupted; the
 > changes to linux-nat.c cut off in a very strange place in child_wait().

Yes.  It seems to have also corrupted Makefile.in.  Its an ssh problem.  I've
resolved that and attach a new patch which should work hopefully.

 > Maybe when it's been cleaned up a little we can look for a way to do
 > this that doesn't involve pthreads.

Nick


[-- Attachment #2: Asynchronous GDB (2) --]
[-- Type: application/octet-stream, Size: 26260 bytes --]

Re: RFC: MI output during program execution

[Daniel Jacobowitz]

On Mon, Sep 19, 2005 at 10:29:10PM +1200, Nick Roberts wrote:
Content-Description: message body text
>  > I've started a merge on current CVS (for some reason gdb-413 seemed to
>  > include everything except the GDB source).  Getting MI output during
>  > program execution seems to be closely related to making GDB asynchronous.
>  > I couldn't attempt such a task on my own but, using the Apple code as a
>  > prototype, it doesn't look too difficult.  When I have something working
>  > perhaps I could put it on a branch.
> 
> I now have something that works for GNU/Linux (probably under limited
> conditions).  With MI it now picks up mi_exec_async_cli_cmd_continuation to
> print the *stopped record, even with CLI commands like "run":

Great!

> I attach the new files and a set of diffs against HEAD from about 20:00 NZST
> (+12 GMT) Sept 19 2005, for anyone who might like to test the functionality.
> If I am given approval to commit these changes to a branch then I will create
> ChangeLog entries (attributed to Apple).
> 
> I presume there is more freedom to committing on a non-release branch.  What
> are the rules?

The rules for a branch are, generally, up to the branch owner.  The
only one I'll insist on is that copyright assignments be handled in the
same way as for HEAD, which is not a problem here.  See:

  http://sources.redhat.com/gdb/current/onlinedocs/gdbint_15.html#SEC133

(which are mostly guidelines rather than rules).  So, you can create a
branch if you'd like.

I took a quick look at the changes, but couldn't make heads or tails
out of what was going on.  Also, I think the diff is corrupted; the
changes to linux-nat.c cut off in a very strange place in child_wait().
Maybe when it's been cleaned up a little we can look for a way to do
this that doesn't involve pthreads.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: RFC: MI output during program execution

[Nick Roberts]

[-- Attachment #1: message body text --]
[-- Type: text/plain, Size: 2705 bytes --]

 > I've started a merge on current CVS (for some reason gdb-413 seemed to
 > include everything except the GDB source).  Getting MI output during
 > program execution seems to be closely related to making GDB asynchronous.
 > I couldn't attempt such a task on my own but, using the Apple code as a
 > prototype, it doesn't look too difficult.  When I have something working
 > perhaps I could put it on a branch.

I now have something that works for GNU/Linux (probably under limited
conditions).  With MI it now picks up mi_exec_async_cli_cmd_continuation to
print the *stopped record, even with CLI commands like "run":

(gdb)
-break-insert main
^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x080484c5",func="main",file="myprog.c",line="55",times="0"}
(gdb)
-interpreter-exec console run
Switching to interpreter "console".
(gdb) Starting program: /home/nickrob/myprog
^running
(gdb)
*stopped,reason="breakpoint-hit",bkptno="1",thread-id="0",frame={addr="0x080484c5",func="main",args=[{name="argc",value="1"},{name="argv",value="0xfee72c74"}],file="myprog.c",fullname="/home/nickrob/myprog.c",line="55"}
(gdb)
-exec-next
^running
(gdb)
*stopped,reason="end-stepping-range",thread-id="0",frame={addr="0x080484d7",func="main",args=[{name="argc",value="1"},{name="argv",value="0xfee72c74"}],file="myprog.c",fullname="/home/nickrob/myprog.c",line="56"}

Such asynchronous behaviour should also help with event notification which
Apple's code also has, but which I have not tried to merge for the moment.

I've changed the files:

cli-interp.c         infcmd.c	          mi-interp.c
defs.h		     inf-loop.c	 	  mi-main.c  
event-loop.c	     inf-ptrace.c	  mi-main.h  
event-loop.h	     infrun.c	 	  target.c   
event-top.c	     interps.c	 	  target.h   
event-top.h	     interps.h	 	  top.c	   
exec.c		     linux-nat.c	  tui-hooks.c
i386-linux-nat.c     linux-thread-db.c	  wrapper.h  
inf-child.c	     Makefile.in      

and added four new ones:

async-nat-inferior.c
async-nat-inferior.h
async-nat-sigthread.c
async-nat-sigthread.h

derived from their macosx-*-*.* counterparts.

Some files had to be changed e.g event-loop.c, event-top.c, inf-loop.c.
Others should probably have been changed elsewhere with different target
methods e.g i386-linux-nat.c linux-thread-db.c.  This is just a starting
point.

I attach the new files and a set of diffs against HEAD from about 20:00 NZST
(+12 GMT) Sept 19 2005, for anyone who might like to test the functionality.
If I am given approval to commit these changes to a branch then I will create
ChangeLog entries (attributed to Apple).

I presume there is more freedom to committing on a non-release branch.  What
are the rules?

Nick


[-- Attachment #2: asynchronous GDB --]
[-- Type: application/octet-stream, Size: 24705 bytes --]

Re: RFC: MI output during program execution

[Daniel Jacobowitz]

On Mon, Sep 12, 2005 at 02:51:47PM +1200, Nick Roberts wrote:
> Stan Shebs writes:
>  > >Could you please tell me where you think the best place to start would be?
>  > >I guess CVS would be better than a tarball.  Would it be best to wait until
>  > >Stan & Klee have completed their merge?
>  > >
>  > Anything you do now will be of value, I don't think our MI stuff
>  > has churned a whole lot, but I would like to put out a drop of
>  > our latest mostly-working CVS anyway, since it's merged up to FSF
>  > sources as of a few days ago, plus most of the local changes have
>  > been at least categorized by purpose. I can't think of any obstacles,
>  > but as a "newbie" in Apple GDB :-) , I need to find out what I can do.
> 
> I've started a merge on current CVS (for some reason gdb-413 seemed to include
> everything except the GDB source).  Getting MI output during program execution
> seems to be closely related to making GDB asynchronous.  I couldn't attempt
> such a task on my own but, using the Apple code as a prototype, it doesn't
> look too difficult.  When I have something working perhaps I could put it on a
> branch.  It's not something that I'll complete in the next week or so and I
> just wanted to outline my intentions.  It will probably only work on the
> platform that I've got (GNU/Linux) so maybe someone more knowledgeable than
> myself can beef it up to make it general enough for mainline.

That's great!  Nick, if you get this started, I'm sure we can find
interested folks to help you get it finished.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: RFC: MI output during program execution

[Nick Roberts]

Stan Shebs writes:
 > >Could you please tell me where you think the best place to start would be?
 > >I guess CVS would be better than a tarball.  Would it be best to wait until
 > >Stan & Klee have completed their merge?
 > >
 > Anything you do now will be of value, I don't think our MI stuff
 > has churned a whole lot, but I would like to put out a drop of
 > our latest mostly-working CVS anyway, since it's merged up to FSF
 > sources as of a few days ago, plus most of the local changes have
 > been at least categorized by purpose. I can't think of any obstacles,
 > but as a "newbie" in Apple GDB :-) , I need to find out what I can do.

I've started a merge on current CVS (for some reason gdb-413 seemed to include
everything except the GDB source).  Getting MI output during program execution
seems to be closely related to making GDB asynchronous.  I couldn't attempt
such a task on my own but, using the Apple code as a prototype, it doesn't
look too difficult.  When I have something working perhaps I could put it on a
branch.  It's not something that I'll complete in the next week or so and I
just wanted to outline my intentions.  It will probably only work on the
platform that I've got (GNU/Linux) so maybe someone more knowledgeable than
myself can beef it up to make it general enough for mainline.

Nick

Re: RFC: MI output during program execution

[Stan Shebs]

Nick Roberts wrote:

>I have heard that Apple are moving MacOSX over to Intel architecture.  Is it
>possible to get a copy of Darwin (or even a preview of MacOSX) for Intel so
>that I can put it on a partition on my PC?  That way I can compare the output
>of my merged version of FSF GDB with that of Apple GDB.
>
Darwin for x86 has been publicly available for some years, just not
that well-known. Go to http://www.opendarwin.org and get ISOs,
source code, mailing lists, and so forth. Their latest code is
Tiger-vintage, so quite current, and I believe it runs on a fairly
wide spectrum of hardware. No GUI unless you want to run X11, but
certainly sufficient for GDB testing.

Stan

Re: RFC: MI output during program execution

[Nick Roberts]

Jim Ingham writes:
 > The CVS repository is not live.  Usually we push whenever we do a  
 > release.  Stan will have to do a push of the current TOT before you  
 > will be able to get it from the CVS server.  gdb-424 is not what you  
 > want anyway.  That's a branch off of the old merge.

That seems to make the CVS repository a bit pointless.  OK, I'll wait
Stan to do this or download the tarball when it becomes available.

 > You can get and install Darwin for MacOS X.  That's freely available  
 > from the OpenDarwin project.  I've never messed around with this,  
 > however, so I don't know anything about how to set it up.  But the  
 > Mac OS X for Intel release only runs on Apple Hardware, and you can  
 > only get it by purchasing an transitional hardware kit from Apple.

Will the latest Darwin run straight off my PC, or do I need transitional
hardware kit from Apple for this also?

Nick

Re: RFC: MI output during program execution

[Jim Ingham]

On Aug 23, 2005, at 7:23 PM, Nick Roberts wrote:

>> As you've no doubt noticed, we have lots of intermingled local
>> changes, so it's going to be a long hard process to contribute
>> everything. While (IMHO) at least 95% of our local changes are
>> of interest for FSF GDB, the context diff alone (no new files,
>> no configury diffs) is 125Kloc! So we'll be most grateful for
>> any help you can lend. I myself have been working on a patch
>> for the basic native configuration, which will help break some
>> of the contribution logjam by enabling testing on Darwin instead
>> of Linux or some other config.
>>
>
> I'm only considering merging the event notification in in MI.  I  
> realise this
> probably involves other files such as infrun.c but hopefully these  
> changes
> can be separated from more extensive ones that you may have made.

Yes, though separating them is a part of the task...

>
>
>>> Could you please tell me where you think the best place to start  
>>> would be?
>>> I guess CVS would be better than a tarball.  Would it be best to  
>>> wait until
>>> Stan & Klee have completed their merge?
>>>
>>>
>> Anything you do now will be of value, I don't think our MI stuff
>> has churned a whole lot, but I would like to put out a drop of
>> our latest mostly-working CVS anyway, since it's merged up to FSF
>> sources as of a few days ago, plus most of the local changes have
>> been at least categorized by purpose. I can't think of any obstacles,
>> but as a "newbie" in Apple GDB :-) , I need to find out what I can  
>> do.
>>
>
> Presumably I can pick this merge from CVS (I've already checked out  
> the current
> source).  Did you tag the merge?  Is it gdb-424?

The CVS repository is not live.  Usually we push whenever we do a  
release.  Stan will have to do a push of the current TOT before you  
will be able to get it from the CVS server.  gdb-424 is not what you  
want anyway.  That's a branch off of the old merge.

>
> I have heard that Apple are moving MacOSX over to Intel  
> architecture.  Is it
> possible to get a copy of Darwin (or even a preview of MacOSX) for  
> Intel so
> that I can put it on a partition on my PC?  That way I can compare  
> the output
> of my merged version of FSF GDB with that of Apple GDB.

You can get and install Darwin for MacOS X.  That's freely available  
from the OpenDarwin project.  I've never messed around with this,  
however, so I don't know anything about how to set it up.  But the  
Mac OS X for Intel release only runs on Apple Hardware, and you can  
only get it by purchasing an transitional hardware kit from Apple.

Jim

Re: RFC: MI output during program execution

[Nick Roberts]

 > As you've no doubt noticed, we have lots of intermingled local
 > changes, so it's going to be a long hard process to contribute
 > everything. While (IMHO) at least 95% of our local changes are
 > of interest for FSF GDB, the context diff alone (no new files,
 > no configury diffs) is 125Kloc! So we'll be most grateful for
 > any help you can lend. I myself have been working on a patch
 > for the basic native configuration, which will help break some
 > of the contribution logjam by enabling testing on Darwin instead
 > of Linux or some other config.

I'm only considering merging the event notification in in MI.  I realise this
probably involves other files such as infrun.c but hopefully these changes
can be separated from more extensive ones that you may have made.

 > >Could you please tell me where you think the best place to start would be?
 > >I guess CVS would be better than a tarball.  Would it be best to wait until
 > >Stan & Klee have completed their merge?
 > >
 > Anything you do now will be of value, I don't think our MI stuff
 > has churned a whole lot, but I would like to put out a drop of
 > our latest mostly-working CVS anyway, since it's merged up to FSF
 > sources as of a few days ago, plus most of the local changes have
 > been at least categorized by purpose. I can't think of any obstacles,
 > but as a "newbie" in Apple GDB :-) , I need to find out what I can do.

Presumably I can pick this merge from CVS (I've already checked out the current
source).  Did you tag the merge?  Is it gdb-424?

I have heard that Apple are moving MacOSX over to Intel architecture.  Is it
possible to get a copy of Darwin (or even a preview of MacOSX) for Intel so
that I can put it on a partition on my PC?  That way I can compare the output
of my merged version of FSF GDB with that of Apple GDB.

Nick

Re: RFC: MI output during program execution

[Stan Shebs]

Nick Roberts wrote:

> > The most current version of our sources is available in tar.gz form at:
> > 
> > http://www.opensource.apple.com/darwinsource/tarballs/other/ 
> > gdb-384.tar.gz
>
>I've downloaded and looked at gdb-413.  I think that your changes do the kinds
>of things that we have been talking about.  I realise that Apple don't want to
>allocate resources to merge these changes into FSF GDB but, as I'm finding it
>difficult to make my own changes, I would like to do this. I guess that you
>will find this agreeable as it will minimise differences between Apple GDB and
>FSF GDB.
>
As you've no doubt noticed, we have lots of intermingled local
changes, so it's going to be a long hard process to contribute
everything. While (IMHO) at least 95% of our local changes are
of interest for FSF GDB, the context diff alone (no new files,
no configury diffs) is 125Kloc! So we'll be most grateful for
any help you can lend. I myself have been working on a patch
for the basic native configuration, which will help break some
of the contribution logjam by enabling testing on Darwin instead
of Linux or some other config.

>
> > I am pretty sure the CVS repository is up to date with this as well  
> > (some projects require an ADC membership, but gdb & friends have  
> > anonymous access).  See
> > 
> > http://developer.apple.com/darwin/tools/cvs/howto.html
> > 
> > for more details.
> > 
> > This code is based on a merge that's almost a year old now.  Stan &  
> > Klee are working away at a more recent merge - we're pretty sure the  
> > patient will survive, but it's definitely not ambulatory yet...
>
>Could you please tell me where you think the best place to start would be?
>I guess CVS would be better than a tarball.  Would it be best to wait until
>Stan & Klee have completed their merge?
>
Anything you do now will be of value, I don't think our MI stuff
has churned a whole lot, but I would like to put out a drop of
our latest mostly-working CVS anyway, since it's merged up to FSF
sources as of a few days ago, plus most of the local changes have
been at least categorized by purpose. I can't think of any obstacles,
but as a "newbie" in Apple GDB :-) , I need to find out what I can do.

Stan

Re: RFC: MI output during program execution

[Nick Roberts]

 > The most current version of our sources is available in tar.gz form at:
 > 
 > http://www.opensource.apple.com/darwinsource/tarballs/other/ 
 > gdb-384.tar.gz

I've downloaded and looked at gdb-413.  I think that your changes do the kinds
of things that we have been talking about.  I realise that Apple don't want to
allocate resources to merge these changes into FSF GDB but, as I'm finding it
difficult to make my own changes, I would like to do this. I guess that you
will find this agreeable as it will minimise differences between Apple GDB and
FSF GDB.

 > I am pretty sure the CVS repository is up to date with this as well  
 > (some projects require an ADC membership, but gdb & friends have  
 > anonymous access).  See
 > 
 > http://developer.apple.com/darwin/tools/cvs/howto.html
 > 
 > for more details.
 > 
 > This code is based on a merge that's almost a year old now.  Stan &  
 > Klee are working away at a more recent merge - we're pretty sure the  
 > patient will survive, but it's definitely not ambulatory yet...

Could you please tell me where you think the best place to start would be?
I guess CVS would be better than a tarball.  Would it be best to wait until
Stan & Klee have completed their merge?

Nick

Re: RFC: MI output during program execution

[Mark Kettenis]

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Thu, 18 Aug 2005 11:15:43 +1200
> 
> I've updated my previous patch to use
> mi_insert/mi_remove_notify_hooks instead of the condition (strcmp
> (interpreter_p, "mi") == 0).  This mechanism could be used more
> pervasively with ui_out_is_mi_like_p to give furher MI output e.g
> reason for stopping.  It could also be used for any event
> notification that is developed for MI.  It might not work with true
> asynchronous behaviour but in that case the existing suppression of
> queries using mi_interp_query_hook must also fail.

If it is decided that this is the way to go, I think you should try to
push all of the code into MI files and just export a single function
that gets called by the code in infrun.c.

Mark

Re: RFC: MI output during program execution

[Nick Roberts]

I've updated my previous patch to use mi_insert/mi_remove_notify_hooks instead
of the condition (strcmp (interpreter_p, "mi") == 0).  This mechanism could be
used more pervasively with ui_out_is_mi_like_p to give furher MI output e.g
reason for stopping.  It could also be used for any event notification that is
developed for MI.  It might not work with true asynchronous behaviour but
in that case the existing suppression of queries using mi_interp_query_hook
must also fail.

Nick


*** defs.h.~1.189.~	2005-08-08 18:20:44.000000000 +1200
--- defs.h	2005-08-18 09:51:14.000000000 +1200
*************** extern struct continuation *cmd_continua
*** 711,716 ****
--- 711,718 ----
  /* Used only by the step_1 function. */
  extern struct continuation *intermediate_continuation;
  
+ extern int gdb_mi_run_status;
+ 
  /* From utils.c */
  extern void add_continuation (void (*)(struct continuation_arg *),
  			      struct continuation_arg *);


*** infrun.c.~1.203~	2005-08-15 10:38:14.000000000 +1200
--- infrun.c	2005-08-18 11:06:01.000000000 +1200
***************
*** 49,54 ****
--- 49,57 ----
  
  #include "gdb_assert.h"
  #include "mi/mi-common.h"
+ #include "mi/mi-out.h"
+ 
+ extern struct ui_file *raw_stdout;
  
  /* Prototypes for local functions */
  
*************** proceed (CORE_ADDR addr, enum target_sig
*** 785,790 ****
--- 788,803 ----
  
    annotate_starting ();
  
+   if (gdb_mi_run_status || (ui_out_is_mi_like_p (uiout)))
+     {
+       fputs_unfiltered ("^running\n", raw_stdout);
+       if (!target_can_async_p ())
+ 	{
+ 	  fputs_unfiltered ("(gdb) \n", raw_stdout);
+ 	   gdb_flush (raw_stdout);
+ 	}
+     }
+ 
    /* Make sure that output from GDB appears before output from the
       inferior.  */
    gdb_flush (gdb_stdout);
*************** Further execution is probably impossible
*** 3136,3141 ****
--- 3149,3164 ----
  done:
    annotate_stopped ();
    observer_notify_normal_stop (stop_bpstat);
+   if (gdb_mi_run_status || (ui_out_is_mi_like_p (uiout)))
+     {
+       fputs_unfiltered ("*stopped", raw_stdout);
+       if (ui_out_is_mi_like_p (uiout))
+ 	{
+ 	  mi_out_put (uiout, raw_stdout);
+ 	  mi_out_rewind (uiout);
+ 	}
+       fputs_unfiltered ("\n", raw_stdout);
+     }
  }
  
  static int


*** mi/mi-interp.c.~1.15.~	2005-08-01 10:45:28.000000000 +1200
--- mi/mi-interp.c	2005-08-18 09:54:29.000000000 +1200
*************** struct mi_interp
*** 48,53 ****
--- 48,55 ----
    struct interp *mi_interp;
  };
  
+ int gdb_mi_run_status = 0;
+ 
  /* These are the interpreter setup, etc. functions for the MI interpreter */
  static void mi_execute_command_wrapper (char *cmd);
  static void mi_command_loop (int mi_version);
*************** static void
*** 280,291 ****
--- 282,295 ----
  mi_insert_notify_hooks (void)
  {
    deprecated_query_hook = mi_interp_query_hook;
+   gdb_mi_run_status = 1;
  }
  
  static void
  mi_remove_notify_hooks (void)
  {
    deprecated_query_hook = NULL;
+   gdb_mi_run_status = 0;
  }
  
  static int
*************** mi_interp_query_hook (const char *ctlstr
*** 294,299 ****
--- 298,309 ----
    return 1;
  }
  
+ static int
+ mi_cli_hook (const char *ctlstr, va_list ap)
+ {
+   return 1;
+ }
+ 
  static void
  mi_execute_command_wrapper (char *cmd)
  {

Re: RFC: MI output during program execution

[Nick Roberts]

> Note that for a truly asynchronous target, what you get is:

> (gdb)
> -exec-continue
> ^running
> (gdb)
> -exec-status
> ^done,status="running"
> (gdb)
> -exec-interrupt
> ^done,reason="signal-received",signal-name="SIGINT",signal- meaning="Interrupt",thread-id="1"
> (gdb)

> Or something like that... So in that case the ^running really is the
> equivalent of the ^done...

I don't really mind if it is ^running or *running, I just want GDB to issue
notification when the inferior starts or stops running after a CLI command is
executed.  Currently I can't tell when to update the UI when such commands are
issued through the GUD buffer.  Daniel suggested this was a different case to
breakpoint-changed or thread-changed but I think it requires a similar
solution.

Nick

Re: RFC: MI output during program execution

[Jim Ingham]

Note that for a truly asynchronous target, what you get is:

(gdb)
-exec-continue
^running
(gdb)
-exec-status
^done,status="running"
(gdb)
-exec-interrupt
^done,reason="signal-received",signal-name="SIGINT",signal- 
meaning="Interrupt",thread-id="1"
(gdb)

Or something like that...  So in that case the ^running really is the  
equivalent of the ^done...

Jim

On Aug 16, 2005, at 5:26 PM, gdb-patches-digest- 
help@sources.redhat.com wrote:

>
>
> Yeah - I'm beginning to think that we should use this:
>
> (gdb)
> -exec-continue
> *running
> ^done
> (gdb)
>
> Instead of the current:
>
> (gdb)
> -exec-continue
> ^running
> (gdb)
>
> It'd definitely have to be mi3 only, though!  This would be a pretty
> big change that frontends would have to adapt to.
>
> The asymmetry between ^running and *stopped will bite us here.  For
> instance, for a CLI command, I'd want roughly:
>
> (gdb)
> -interpreter-exec console "continue"
> *running
> ^done
> (gdb)
>
> Anyway, food for thought.
>
> -- 
> Daniel Jacobowitz
> CodeSourcery, LLC
>

Re: RFC: MI output during program execution

[Nick Roberts]

> +   if ((strcmp (interpreter_p, "mi") == 0) || (ui_out_is_mi_like_p (uiout)))
> +       fputs_unfiltered ("*stopped", raw_stdout);
> +   if (ui_out_is_mi_like_p (uiout))
> +     {
> +       mi_out_put (uiout, raw_stdout);
> +       mi_out_rewind (uiout);
> +     }
> +   fputs_unfiltered ("\n", raw_stdout);

I mean:

+   if ((strcmp (interpreter_p, "mi") == 0) || (ui_out_is_mi_like_p (uiout)))
+     {
+       fputs_unfiltered ("*stopped", raw_stdout);
+       if (ui_out_is_mi_like_p (uiout))
+ 	{
+ 	  mi_out_put (uiout, raw_stdout);
+ 	  mi_out_rewind (uiout);
+ 	}
+       fputs_unfiltered ("\n", raw_stdout);
+     }

of course.

Nick

Re: RFC: MI output during program execution

[Mark Kettenis]

> Date: Sat, 13 Aug 2005 01:04:14 -0400
> From: Daniel Jacobowitz <drow@false.org>
> 
> Or do as I described earlier today, and add a new mechanism
> specifically designed to notify interpreters of events that could be
> interesting (which might meet Eli's concerns about misusing observers,
> but we'd have to ask him!), or else call into the MI interpreter
> directly from the code without messing with any kind of mechanism.

Let's not add any new mechanisms before we've removed all traces of
the deprecated ones shall we?

Mark

Re: RFC: MI output during program execution

[Daniel Jacobowitz]

On Sat, Aug 13, 2005 at 08:53:33AM -0400, Bob Rossi wrote:
> The strange this is, it doesn't look like the "event" approach was a
> replacement for the "hook" approach, unless it was a long time coming.
> For instance, in breakpoint.c, 

I don't know what the event interface was designed for; it predates my
involvement with GDB.  The mailing list archives are a good reference
at moments like this.

In any case, I don't think it's a widely adopted infrastructure and I
don't think it's doing much good.  I'd rather add something more
specific, and see about removing both the hooks and the events, unless
someone can give me a reason to the contrary.  Are events currently
used?  For what?

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: RFC: MI output during program execution

[Bob Rossi]

> > Obviously, there is a 1-1 relationship between the FE and GDB, but I
> > don't think that should be a big deal.
> 
> It is a big deal.  Problems with an essential one-to-one relationship
> don't need the complication of an implementation designed for
> one-to-many relations.  There the observer pattern doesn't make any
> sense.  On the other hand, if a relationship is one-to-many but just
> happens to be one-to-one because there is only one of many finished
> implementations, the observer pattern makes sense.

Yes, I see that now. Thanks.

Bob Rossi

Re: RFC: MI output during program execution

[Bob Rossi]

On Fri, Aug 12, 2005 at 11:47:24PM -0700, Jim Ingham wrote:
> 
> On Aug 12, 2005, at 10:04 PM, Daniel Jacobowitz wrote:
> 
> >On Fri, Aug 12, 2005 at 09:15:42PM -0400, Bob Rossi wrote:
> >
> >>On Fri, Aug 12, 2005 at 05:33:25PM -0700, Jim Ingham wrote:
> >>
> >>>>OK, unfortunatly, I'm still trying to catch up here. I think I
> >>>>understand the observer approach, however, what is the event  
> >>>>approach?
> >>>>Is that different than the "hooks" you have?
> >>>>
> >>>
> >>>So it LOOKS like the "events" are supposed to be the replacements  
> >>>for
> >>>the hooks...
> >>>
> >>>But then there's the whole observer thing, which from what I read of
> >>>the gdb-patches traffic at the time was supposed to be a more  
> >>>general
> >>>solution for watching interesting events.  But it doesn't seem to be
> >>>used all that much.
> >>>
> >>>So I am not really sure what's supposed to be happening here.
> >>>
> >>>Moving from hooks to events seems a trivial formal exercise.  I  
> >>>don't
> >>>know if they will get deprecated soon or what, however...
> >>>
> >>
> >>Jim thanks for all the help! Really.
> >>
> >>Can anyone reliable answer if hooks or events are supposed to be  
> >>used in
> >>the future for GDB? if neither of these, is there another approach?
> >>
> >>If there is no approach that the core GDB developers prefer, or know
> >>that are already in place, we are free to choose from any approach.
> >>
> >
> >Or do as I described earlier today, and add a new mechanism
> >specifically designed to notify interpreters of events that could be
> >interesting (which might meet Eli's concerns about misusing observers,
> >but we'd have to ask him!), or else call into the MI interpreter
> >directly from the code without messing with any kind of mechanism.
> 
> The hooks worked just fine for this purpose.  Dunno why they were  
> deprecated.  The events which are in all the same places, and work  
> pretty much the same way, also should be just fine...  We should pick  
> one of these, I think, rather than invent yet another.

Agreed, and if I understand them, both Daniel and Eli OK this idea.

The strange this is, it doesn't look like the "event" approach was a
replacement for the "hook" approach, unless it was a long time coming.
For instance, in breakpoint.c, 

   1.167        (cagney   21-Apr-04):   if (deprecated_create_breakpoint_hook)
   1.167        (cagney   21-Apr-04):     deprecated_create_breakpoint_hook (b);
   1.2          (cagney   23-Feb-00):   breakpoint_create_event (b->number);

The event's seem to have been there forever. Apparently, I have no idea
to figure out why someone Deprecated a piece of software in GDB because
the ChangeLog just says,
   2004-04-21  Andrew Cagney  <cagney@redhat.com>

           * annotate.h (deprecated_annotate_starting_hook)
           (deprecated_annotate_stopped_hook)
           (deprecated_annotate_exited_hook)
           (deprecated_annotate_signal_hook)
           (deprecated_annotate_signalled_hook): Deprecate.
           ...

Anyways, it looks like all of the "hooks" have been removed and the
replacement is events, like you have noticed Jim. The problem I see is
that gdb-events.[hc] is supposed to be the interface. However, I notice
2 problems.

The first is that the events layer looks like it is unable to provide
events to more than one listener. There is a single static event
variable in the body of gdb-events.c. I would think more than one
subsystem would want to know about the events that have been gathered so
far. Maybe that variable should be a list?

Second, the function that installs the event hooks is deprecated! So, it
appears that both the hooks and the custom events have been deprecated.
This is odd. How would the event interface be usable if the custom event
hooks (very bad name, since this is for events, not hooks) function was 
deprecated?

1.15         (cagney   26-Jun-04): extern struct gdb_events *deprecated_set_gdb_event_hooks (struct gd b_events *vector);     

This change is *not* in the ChangeLog, so I have no idea why it
was changed.

Anyways, the events look just fine to me, as long as the above questions
can be satisfied.

Thanks,
Bob Rossi

Re: RFC: MI output during program execution

[Eli Zaretskii]

> Date: Sat, 13 Aug 2005 01:04:14 -0400
> From: Daniel Jacobowitz <drow@false.org>
> 
> Or do as I described earlier today, and add a new mechanism
> specifically designed to notify interpreters of events that could be
> interesting (which might meet Eli's concerns about misusing observers,
> but we'd have to ask him!)

I won't object to such a mechanism.

> or else call into the MI interpreter
> directly from the code without messing with any kind of mechanism.

And neither to this implementation.

Re: RFC: MI output during program execution

[Eli Zaretskii]

> Date: Fri, 12 Aug 2005 16:57:14 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: gdb-patches@sources.redhat.com
> 
> In any case, I don't know that the observers implementation, per se, is
> a good fit for this particular usage anyway.  MI is not an optional
> component, nor would most of the events in question be optional
> components; the data flow is simple, just as you described above.
> We can just call MI at the right points.

If it's easy to do that, let's do it.

> Or add a small level of abstraction, and call all registered
> interfaces (TUI, CLI, MI) and see if any of them need to generate
> notifications.

Or this.

Re: RFC: MI output during program execution

[Eli Zaretskii]

> Date: Fri, 12 Aug 2005 16:45:41 -0400
> From: Daniel Jacobowitz <drow@false.org>
> 
> On Fri, Aug 12, 2005 at 04:30:52PM -0400, Bob Rossi wrote:
> > OK, this seems reasonable. One thing to note is that the FE may be in C++
> > or Java, which would lend nicely to the Observer design pattern. CGDB is
> > written in C, so this doesn't really matter to me.
> 
> Not relevant here - these are observers _within_ GDB.

Exactly.  Those FEs are separate programs, so GDB's internal observers
are unrelated to them or their programming language.

Re: RFC: MI output during program execution

[Jim Ingham]

On Aug 12, 2005, at 10:04 PM, Daniel Jacobowitz wrote:

> On Fri, Aug 12, 2005 at 09:15:42PM -0400, Bob Rossi wrote:
>
>> On Fri, Aug 12, 2005 at 05:33:25PM -0700, Jim Ingham wrote:
>>
>>>> OK, unfortunatly, I'm still trying to catch up here. I think I
>>>> understand the observer approach, however, what is the event  
>>>> approach?
>>>> Is that different than the "hooks" you have?
>>>>
>>>
>>> So it LOOKS like the "events" are supposed to be the replacements  
>>> for
>>> the hooks...
>>>
>>> But then there's the whole observer thing, which from what I read of
>>> the gdb-patches traffic at the time was supposed to be a more  
>>> general
>>> solution for watching interesting events.  But it doesn't seem to be
>>> used all that much.
>>>
>>> So I am not really sure what's supposed to be happening here.
>>>
>>> Moving from hooks to events seems a trivial formal exercise.  I  
>>> don't
>>> know if they will get deprecated soon or what, however...
>>>
>>
>> Jim thanks for all the help! Really.
>>
>> Can anyone reliable answer if hooks or events are supposed to be  
>> used in
>> the future for GDB? if neither of these, is there another approach?
>>
>> If there is no approach that the core GDB developers prefer, or know
>> that are already in place, we are free to choose from any approach.
>>
>
> Or do as I described earlier today, and add a new mechanism
> specifically designed to notify interpreters of events that could be
> interesting (which might meet Eli's concerns about misusing observers,
> but we'd have to ask him!), or else call into the MI interpreter
> directly from the code without messing with any kind of mechanism.

The hooks worked just fine for this purpose.  Dunno why they were  
deprecated.  The events which are in all the same places, and work  
pretty much the same way, also should be just fine...  We should pick  
one of these, I think, rather than invent yet another.

Jim

Re: RFC: MI output during program execution

[Daniel Jacobowitz]

On Fri, Aug 12, 2005 at 09:15:42PM -0400, Bob Rossi wrote:
> On Fri, Aug 12, 2005 at 05:33:25PM -0700, Jim Ingham wrote:
> > >OK, unfortunatly, I'm still trying to catch up here. I think I
> > >understand the observer approach, however, what is the event approach?
> > >Is that different than the "hooks" you have?
> > 
> > So it LOOKS like the "events" are supposed to be the replacements for  
> > the hooks...
> > 
> > But then there's the whole observer thing, which from what I read of  
> > the gdb-patches traffic at the time was supposed to be a more general  
> > solution for watching interesting events.  But it doesn't seem to be  
> > used all that much.
> >
> > So I am not really sure what's supposed to be happening here.
> > 
> > Moving from hooks to events seems a trivial formal exercise.  I don't  
> > know if they will get deprecated soon or what, however...
> 
> Jim thanks for all the help! Really.
> 
> Can anyone reliable answer if hooks or events are supposed to be used in
> the future for GDB? if neither of these, is there another approach?
> 
> If there is no approach that the core GDB developers prefer, or know
> that are already in place, we are free to choose from any approach.

Or do as I described earlier today, and add a new mechanism
specifically designed to notify interpreters of events that could be
interesting (which might meet Eli's concerns about misusing observers,
but we'd have to ask him!), or else call into the MI interpreter
directly from the code without messing with any kind of mechanism.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: RFC: MI output during program execution

[Bob Rossi]

On Fri, Aug 12, 2005 at 05:33:25PM -0700, Jim Ingham wrote:
> >OK, unfortunatly, I'm still trying to catch up here. I think I
> >understand the observer approach, however, what is the event approach?
> >Is that different than the "hooks" you have?
> 
> So it LOOKS like the "events" are supposed to be the replacements for  
> the hooks...
> 
> But then there's the whole observer thing, which from what I read of  
> the gdb-patches traffic at the time was supposed to be a more general  
> solution for watching interesting events.  But it doesn't seem to be  
> used all that much.
>
> So I am not really sure what's supposed to be happening here.
> 
> Moving from hooks to events seems a trivial formal exercise.  I don't  
> know if they will get deprecated soon or what, however...

Jim thanks for all the help! Really.

Can anyone reliable answer if hooks or events are supposed to be used in
the future for GDB? if neither of these, is there another approach?

If there is no approach that the core GDB developers prefer, or know
that are already in place, we are free to choose from any approach.

Bob Rossi

Re: RFC: MI output during program execution

[Daniel Jacobowitz]

On Fri, Aug 12, 2005 at 08:49:40PM -0400, Bob Rossi wrote:
> I believe I understand now. I think you are saying that at certain 
> interesting points in GDB (when it realizes breakpoints have changed, 
> or the inferior changes state), then an event is generated, and the 
> MI (still inside GDB), is the consumer of that event. Is this correct?
> 
> With this in mind, the way MI gets the data (callbacks, Observer
> pattern, hooks/events) is what is important, and *not* the way the MI
> jet's this data to the FE. Is this correct?

All correct.  The MI pipes the information to the FE, well, via MI...

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: RFC: MI output during program execution

[Bob Rossi]

On Fri, Aug 12, 2005 at 04:45:41PM -0400, Daniel Jacobowitz wrote:
> On Fri, Aug 12, 2005 at 04:30:52PM -0400, Bob Rossi wrote:
> > OK, this seems reasonable. One thing to note is that the FE may be in C++
> > or Java, which would lend nicely to the Observer design pattern. CGDB is
> > written in C, so this doesn't really matter to me.
> 
> Not relevant here - these are observers _within_ GDB.

Wow, I was defiantly confused on what was being talked about here until
you pointed this out, thanks. Of course, since I have my FE hat on most
of the time, I was thinking that GDB was the Subject (which knew about
all it's Observers), and the FE's were the Observers.

Now I understand that this solution is all internal to GDB, and the FE
really has nothing to do with the problem besides consuming the output
of GDB. 

I believe I understand now. I think you are saying that at certain 
interesting points in GDB (when it realizes breakpoints have changed, 
or the inferior changes state), then an event is generated, and the 
MI (still inside GDB), is the consumer of that event. Is this correct?

With this in mind, the way MI gets the data (callbacks, Observer
pattern, hooks/events) is what is important, and *not* the way the MI
jet's this data to the FE. Is this correct?

Thanks,
Bob Rossi

Re: RFC: MI output during program execution

[Jim Ingham]

Bob,

On Aug 12, 2005, at 5:22 PM, Bob Rossi wrote:

>>> Thanks for all the guidence so far. Even though you have not  
>>> attempted
>>> the observer approach, how do you feel about it? Is this something
>>> that
>>> you think could be accomplished with the current FSF GDB? Nick,  
>>> Daniel
>>> and Eli, do you like this approach? I'm sure I could find some  
>>> time to
>>> get something going in this direction, with a little bit of thought.
>>>
>>
>> This should work fine.  Actually, the "events" that Keith introduced
>> seems easier to do, since it looks like there's already an event call
>> wherever there is a "deprecated_*_hook" but I am not sure what the
>> difference between events & observers is supposed to be...
>>
>
> OK, unfortunatly, I'm still trying to catch up here. I think I
> understand the observer approach, however, what is the event approach?
> Is that different than the "hooks" you have?

I don't have a good answer here, there is some history that I don't  
fully understand.  There used to be _hook functions, that you put in  
various interesting places in gdb, and called like:

   if (create_breakpoint_hook)
     create_breakpoint_hook (b);

So in the MI, when I am about to call into the cli interpreter, first  
I put in place a bunch of hooks, and then they get called to tell me  
if anything interesting happens.

In current TOT gdb, I see instead:

   if (deprecated_create_breakpoint_hook)
     deprecated_create_breakpoint_hook (b);
   breakpoint_create_event (b->number);

where breakpoint_create_event does:

void
breakpoint_create_event (int b)
{
   if (gdb_events_debug)
     fprintf_unfiltered (gdb_stdlog, "breakpoint_create_event\n");
   if (!current_event_hooks->breakpoint_create)
     return;
   current_event_hooks->breakpoint_create (b);
}

Okay...

So it LOOKS like the "events" are supposed to be the replacements for  
the hooks...

But then there's the whole observer thing, which from what I read of  
the gdb-patches traffic at the time was supposed to be a more general  
solution for watching interesting events.  But it doesn't seem to be  
used all that much.

So I am not really sure what's supposed to be happening here.

Moving from hooks to events seems a trivial formal exercise.  I don't  
know if they will get deprecated soon or what, however...

>
>
>>> Anyone else willing to work towards this solution?
>>>
>>> I really like Daniel's idea of just alerting the user that
>>> something has
>>> changed, instead of actually giving the user the data. For  
>>> instance he
>>> had,
>>>
>>>   =breakpoint-changed,[bpnum="1",state="disabled"]
>>>   =thread-changed,[thread="2"]
>>>
>>> I might even prefer,
>>>   =breakpoint-changed,thread-changed
>>> which would then allow the FE to call -list-breakpoints or  
>>> whatever if
>>> they are interested.
>>>
>>
>> Why?  These sorts of events are never going to have that much data in
>> them.  Why would you want to force another round trip just to avoid
>> packaging up some data that you already have on hand.  That just
>> makes the UI's job more complicated.  For instance, if a breakpoint
>> command set a breakpoint and started the target going again,
>> currently you are going to have to stop the target to get the
>> breakpoint list, which seems silly.  And even if we made "-break-
>> info" a command that you can issue while the target is going, what if
>> it stopped again between you sending the break info and it getting
>> processed.  You will get another async message before you get the
>> break info response...
>>
>> Of course the UI has got to be robust against this sort of thing, but
>> I see no reason to make the job arbitrarily complex.
>>
>> Again, what is your reason for wanting to do this?
>>
>
> Well, I just figured it would be easier to say, "This has changed",
> instead of giving the entire change. However, if I'm wrong here,  
> that is
> fine. It's easy to change this kind of thing once the functionality is
> in place. As long as the approach is aggreed on, then I think we'll  
> all
> be happy.

Cool...

Jim

Re: RFC: MI output during program execution

[Bob Rossi]

> >Thanks for all the guidence so far. Even though you have not attempted
> >the observer approach, how do you feel about it? Is this something  
> >that
> >you think could be accomplished with the current FSF GDB? Nick, Daniel
> >and Eli, do you like this approach? I'm sure I could find some time to
> >get something going in this direction, with a little bit of thought.
> 
> This should work fine.  Actually, the "events" that Keith introduced  
> seems easier to do, since it looks like there's already an event call  
> wherever there is a "deprecated_*_hook" but I am not sure what the  
> difference between events & observers is supposed to be...

OK, unfortunatly, I'm still trying to catch up here. I think I
understand the observer approach, however, what is the event approach?
Is that different than the "hooks" you have? 

> >Anyone else willing to work towards this solution?
> >
> >I really like Daniel's idea of just alerting the user that  
> >something has
> >changed, instead of actually giving the user the data. For instance he
> >had,
> >
> >   =breakpoint-changed,[bpnum="1",state="disabled"]
> >   =thread-changed,[thread="2"]
> >
> >I might even prefer,
> >   =breakpoint-changed,thread-changed
> >which would then allow the FE to call -list-breakpoints or whatever if
> >they are interested.
> 
> Why?  These sorts of events are never going to have that much data in  
> them.  Why would you want to force another round trip just to avoid  
> packaging up some data that you already have on hand.  That just  
> makes the UI's job more complicated.  For instance, if a breakpoint  
> command set a breakpoint and started the target going again,  
> currently you are going to have to stop the target to get the  
> breakpoint list, which seems silly.  And even if we made "-break- 
> info" a command that you can issue while the target is going, what if  
> it stopped again between you sending the break info and it getting  
> processed.  You will get another async message before you get the  
> break info response...
> 
> Of course the UI has got to be robust against this sort of thing, but  
> I see no reason to make the job arbitrarily complex.
> 
> Again, what is your reason for wanting to do this?

Well, I just figured it would be easier to say, "This has changed",
instead of giving the entire change. However, if I'm wrong here, that is
fine. It's easy to change this kind of thing once the functionality is
in place. As long as the approach is aggreed on, then I think we'll all
be happy.

Bob Rossi

Re: RFC: MI output during program execution

[Daniel Jacobowitz]

On Thu, Aug 11, 2005 at 09:28:10PM -0400, Bob Rossi wrote:
> > Remember I haven't done this with observers or events yet.  The way I  
> > did it with hooks, the result of the hooks is gathered into the  
> > "^done" or the other termination states for the command.  So for  
> > instance, if you run gdb on itself, and do:
> 
> Hi Jim,
> 
> Thanks for all the guidence so far. Even though you have not attempted
> the observer approach, how do you feel about it? Is this something that
> you think could be accomplished with the current FSF GDB? Nick, Daniel
> and Eli, do you like this approach? I'm sure I could find some time to 
> get something going in this direction, with a little bit of thought.

Just to clarify what I said downthread to Eli: I don't think that this
requires "observers" in any sense.  I think we want to do something
specific to notifying interpreters, or even something specific to
notifying the MI interpreter (I'm not sure which is a better idea, to
be honest).  So perhaps you should find something else to call it :-)

> I really like Daniel's idea of just alerting the user that something has
> changed, instead of actually giving the user the data. For instance he
> had,
> 
>    =breakpoint-changed,[bpnum="1",state="disabled"]
>    =thread-changed,[thread="2"]

That wasn't my idea, although they were my examples - those were
exactly the available information.  I support providing the data,
unless it becomes large or complicated.  Which it may especially for
breakpoints!  We need an implementation to experiment with.

> This is very similar to how annotate=2 solved the problem for when
> breakpoints changed. The only wierd issue that happened with this
> approach is that the data breakpoint-changed was literally outputted
> thousands and thousands of times in certain circumstances. (compiled
> program with optimizations).

Fortunately, this is pretty easy to handle in MI land.  I suspect that
we will usually only want the notification once if it's just
=breakpoint-changed.  Especially if we can manage the interface so that
user events generate notifications but program events don't need to...

The example that concerns me is loading a shared library and having it
shuffle many breakpoints around.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: RFC: MI output during program execution

[Daniel Jacobowitz]

On Fri, Aug 12, 2005 at 08:13:17PM +0300, Eli Zaretskii wrote:
> I dislike using observers because, in a C program, that looks
> suspiciously like the coder doesn't know what the program is doing.  C
> is not a polymorphic language, so in a C program events happen and
> data of certain type arrives via a 100% predictable and deterministic
> path.  If you know where the event happens which you want to hook,
> simply arrange for your function to be called directly by whatever
> generates or receives that event.

The main reason that I have advocated observers in GDB, in the past, is
for the cases where "we don't know what the program is doing"
- things specific to a target or group of targets or an optional
module, so that we don't have #ifdefs all over the code for targets
which ought to be self-contained.  Also, even in C there can be
multiple places logically generating an "event" - for a perfect
example, look at observer_notify_inferior_created.

I do understand your objections, though I'm not sure what to do about
them.  Personally, I'd love to solve the problem by switching to C++.

In any case, I don't know that the observers implementation, per se, is
a good fit for this particular usage anyway.  MI is not an optional
component, nor would most of the events in question be optional
components; the data flow is simple, just as you described above.
We can just call MI at the right points.  Or add a small level of
abstraction, and call all registered interfaces (TUI, CLI, MI) and see
if any of them need to generate notifications.  That doesn't
change the basic idea of notifying MI at interesting events, which I
think is a nice one.


-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: RFC: MI output during program execution

[Mark Kettenis]

> Date: Fri, 12 Aug 2005 16:30:52 -0400
> From: Bob Rossi <bob@brasko.net>
> 
> On Fri, Aug 12, 2005 at 08:13:17PM +0300, Eli Zaretskii wrote:
> > > Date: Fri, 12 Aug 2005 07:49:29 -0400
> > > From: Bob Rossi <bob@brasko.net>
> > > Cc: gdb-patches@sources.redhat.com
> > > 
> > > On Fri, Aug 12, 2005 at 12:43:19PM +0300, Eli Zaretskii wrote:
> > > > > Date: Thu, 11 Aug 2005 21:28:10 -0400
> > > > > From: Bob Rossi <bob@brasko.net>
> > > > > Cc: Eli Zaretskii <eliz@gnu.org>, gdb-patches@sources.redhat.com
> > > > > 
> > > > > Thanks for all the guidence so far. Even though you have not attempted
> > > > > the observer approach, how do you feel about it? Is this something that
> > > > > you think could be accomplished with the current FSF GDB? Nick, Daniel
> > > > > and Eli, do you like this approach?
> > > > 
> > > > The record will show that I dislike using observers in core GDB
> > > > sources (i.e. in the sources released with official GDB
> > > > distributions).  But my opinions on this are usually voted down.
> > > 
> > > I would like to become more educated on the pros/cons of the two possible
> > > approaches in solving this problem. What do you not like about the
> > > observer approach that the hook approach solves better?
> > 
> > I'm not sure what you mean by ``the hook approach''.  From my point of
> > view, observers are simply one implementation of the hook approach.
> 
> Yes, as I was thinking about this later, I realized that this was true.
> However, I was thinking the the "hook approach=>jim's implementation",
> was simply an implementation of the observer design pattern. The
> observer pattern can be defined as,
> 
>    Define a one-to-many relationship between objects so that when one
>    object changes state, all its dependents are notified and updated
>    automatically.
> 
> Obviously, there is a 1-1 relationship between the FE and GDB, but I
> don't think that should be a big deal.

It is a big deal.  Problems with an essential one-to-one relationship
don't need the complication of an implementation designed for
one-to-many relations.  There the observer pattern doesn't make any
sense.  On the other hand, if a relationship is one-to-many but just
happens to be one-to-one because there is only one of many finished
implementations, the observer pattern makes sense.

> > I dislike using observers because, in a C program, that looks
> > suspiciously like the coder doesn't know what the program is doing.  C
> > is not a polymorphic language, so in a C program events happen and
> > data of certain type arrives via a 100% predictable and deterministic
> > path.  If you know where the event happens which you want to hook,
> > simply arrange for your function to be called directly by whatever
> > generates or receives that event.
> 
> OK, this seems reasonable. One thing to note is that the FE may be in C++
> or Java, which would lend nicely to the Observer design pattern. CGDB is
> written in C, so this doesn't really matter to me.

Oh come on.  A lot of those "modern" languages are just syntactic
sugar (and in the case of C++ its a full wedding cake that makes you
sick if you eat too much of it).  C programmers have been using the
observer pattern for ages, even before the name observer pattern even
existed.

> > In addition, using observers raises an issue with multiple observers
> > watching the same events and stepping on each other's feet.  In other
> > words, the observer facility doesn't promise anything about the order
> > in which the observers are invoked, and doesn't give us control on the
> > order, so a potential arises for conflicts, if several observers futz
> > with the same data structures or try to produce opposite effects.
>

This is the real reason to be careful with the observer pattern.  If
you encounter interdependencies between observers, the observer
pattern is not the right solution for your problem.

Mark

Re: RFC: MI output during program execution

[Daniel Jacobowitz]

On Fri, Aug 12, 2005 at 04:30:52PM -0400, Bob Rossi wrote:
> OK, this seems reasonable. One thing to note is that the FE may be in C++
> or Java, which would lend nicely to the Observer design pattern. CGDB is
> written in C, so this doesn't really matter to me.

Not relevant here - these are observers _within_ GDB.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: RFC: MI output during program execution

[Bob Rossi]

On Fri, Aug 12, 2005 at 08:13:17PM +0300, Eli Zaretskii wrote:
> > Date: Fri, 12 Aug 2005 07:49:29 -0400
> > From: Bob Rossi <bob@brasko.net>
> > Cc: gdb-patches@sources.redhat.com
> > 
> > On Fri, Aug 12, 2005 at 12:43:19PM +0300, Eli Zaretskii wrote:
> > > > Date: Thu, 11 Aug 2005 21:28:10 -0400
> > > > From: Bob Rossi <bob@brasko.net>
> > > > Cc: Eli Zaretskii <eliz@gnu.org>, gdb-patches@sources.redhat.com
> > > > 
> > > > Thanks for all the guidence so far. Even though you have not attempted
> > > > the observer approach, how do you feel about it? Is this something that
> > > > you think could be accomplished with the current FSF GDB? Nick, Daniel
> > > > and Eli, do you like this approach?
> > > 
> > > The record will show that I dislike using observers in core GDB
> > > sources (i.e. in the sources released with official GDB
> > > distributions).  But my opinions on this are usually voted down.
> > 
> > I would like to become more educated on the pros/cons of the two possible
> > approaches in solving this problem. What do you not like about the
> > observer approach that the hook approach solves better?
> 
> I'm not sure what you mean by ``the hook approach''.  From my point of
> view, observers are simply one implementation of the hook approach.

Yes, as I was thinking about this later, I realized that this was true.
However, I was thinking the the "hook approach=>jim's implementation",
was simply an implementation of the observer design pattern. The
observer pattern can be defined as,

   Define a one-to-many relationship between objects so that when one
   object changes state, all its dependents are notified and updated
   automatically.

Obviously, there is a 1-1 relationship between the FE and GDB, but I
don't think that should be a big deal.

> I dislike using observers because, in a C program, that looks
> suspiciously like the coder doesn't know what the program is doing.  C
> is not a polymorphic language, so in a C program events happen and
> data of certain type arrives via a 100% predictable and deterministic
> path.  If you know where the event happens which you want to hook,
> simply arrange for your function to be called directly by whatever
> generates or receives that event.

OK, this seems reasonable. One thing to note is that the FE may be in C++
or Java, which would lend nicely to the Observer design pattern. CGDB is
written in C, so this doesn't really matter to me.

> In addition, using observers raises an issue with multiple observers
> watching the same events and stepping on each other's feet.  In other
> words, the observer facility doesn't promise anything about the order
> in which the observers are invoked, and doesn't give us control on the
> order, so a potential arises for conflicts, if several observers futz
> with the same data structures or try to produce opposite effects.

Agreed. However, there is only a single observer in this case, right?

Thanks for the info,
Bob Rossi

Re: RFC: MI output during program execution

[Eli Zaretskii]

> Date: Fri, 12 Aug 2005 07:49:29 -0400
> From: Bob Rossi <bob@brasko.net>
> Cc: gdb-patches@sources.redhat.com
> 
> On Fri, Aug 12, 2005 at 12:43:19PM +0300, Eli Zaretskii wrote:
> > > Date: Thu, 11 Aug 2005 21:28:10 -0400
> > > From: Bob Rossi <bob@brasko.net>
> > > Cc: Eli Zaretskii <eliz@gnu.org>, gdb-patches@sources.redhat.com
> > > 
> > > Thanks for all the guidence so far. Even though you have not attempted
> > > the observer approach, how do you feel about it? Is this something that
> > > you think could be accomplished with the current FSF GDB? Nick, Daniel
> > > and Eli, do you like this approach?
> > 
> > The record will show that I dislike using observers in core GDB
> > sources (i.e. in the sources released with official GDB
> > distributions).  But my opinions on this are usually voted down.
> 
> I would like to become more educated on the pros/cons of the two possible
> approaches in solving this problem. What do you not like about the
> observer approach that the hook approach solves better?

I'm not sure what you mean by ``the hook approach''.  From my point of
view, observers are simply one implementation of the hook approach.

I dislike using observers because, in a C program, that looks
suspiciously like the coder doesn't know what the program is doing.  C
is not a polymorphic language, so in a C program events happen and
data of certain type arrives via a 100% predictable and deterministic
path.  If you know where the event happens which you want to hook,
simply arrange for your function to be called directly by whatever
generates or receives that event.

In addition, using observers raises an issue with multiple observers
watching the same events and stepping on each other's feet.  In other
words, the observer facility doesn't promise anything about the order
in which the observers are invoked, and doesn't give us control on the
order, so a potential arises for conflicts, if several observers futz
with the same data structures or try to produce opposite effects.

I'm sure you will find more detail about this in the archives, just
search for threads that mentioned observers.

Re: RFC: MI output during program execution

[Jim Ingham]

On Aug 11, 2005, at 6:28 PM, Bob Rossi wrote:

>> Remember I haven't done this with observers or events yet.  The way I
>> did it with hooks, the result of the hooks is gathered into the
>> "^done" or the other termination states for the command.  So for
>> instance, if you run gdb on itself, and do:
>>
>
> Hi Jim,
>
> Thanks for all the guidence so far. Even though you have not attempted
> the observer approach, how do you feel about it? Is this something  
> that
> you think could be accomplished with the current FSF GDB? Nick, Daniel
> and Eli, do you like this approach? I'm sure I could find some time to
> get something going in this direction, with a little bit of thought.

This should work fine.  Actually, the "events" that Keith introduced  
seems easier to do, since it looks like there's already an event call  
wherever there is a "deprecated_*_hook" but I am not sure what the  
difference between events & observers is supposed to be...

>
> Anyone else willing to work towards this solution?
>
> I really like Daniel's idea of just alerting the user that  
> something has
> changed, instead of actually giving the user the data. For instance he
> had,
>
>    =breakpoint-changed,[bpnum="1",state="disabled"]
>    =thread-changed,[thread="2"]
>
> I might even prefer,
>    =breakpoint-changed,thread-changed
> which would then allow the FE to call -list-breakpoints or whatever if
> they are interested.

Why?  These sorts of events are never going to have that much data in  
them.  Why would you want to force another round trip just to avoid  
packaging up some data that you already have on hand.  That just  
makes the UI's job more complicated.  For instance, if a breakpoint  
command set a breakpoint and started the target going again,  
currently you are going to have to stop the target to get the  
breakpoint list, which seems silly.  And even if we made "-break- 
info" a command that you can issue while the target is going, what if  
it stopped again between you sending the break info and it getting  
processed.  You will get another async message before you get the  
break info response...

Of course the UI has got to be robust against this sort of thing, but  
I see no reason to make the job arbitrarily complex.

Again, what is your reason for wanting to do this?

Jim


>
> This is very similar to how annotate=2 solved the problem for when
> breakpoints changed. The only wierd issue that happened with this
> approach is that the data breakpoint-changed was literally outputted
> thousands and thousands of times in certain circumstances. (compiled
> program with optimizations).
>
> Thanks,
> Bob Rossi
>

Re: RFC: MI output during program execution

[Bob Rossi]

On Fri, Aug 12, 2005 at 12:43:19PM +0300, Eli Zaretskii wrote:
> > Date: Thu, 11 Aug 2005 21:28:10 -0400
> > From: Bob Rossi <bob@brasko.net>
> > Cc: Eli Zaretskii <eliz@gnu.org>, gdb-patches@sources.redhat.com
> > 
> > Thanks for all the guidence so far. Even though you have not attempted
> > the observer approach, how do you feel about it? Is this something that
> > you think could be accomplished with the current FSF GDB? Nick, Daniel
> > and Eli, do you like this approach?
> 
> The record will show that I dislike using observers in core GDB
> sources (i.e. in the sources released with official GDB
> distributions).  But my opinions on this are usually voted down.

I would like to become more educated on the pros/cons of the two possible
approaches in solving this problem. What do you not like about the
observer approach that the hook approach solves better?

Bob Rossi

Re: RFC: MI output during program execution

[Eli Zaretskii]

> Date: Thu, 11 Aug 2005 21:28:10 -0400
> From: Bob Rossi <bob@brasko.net>
> Cc: Eli Zaretskii <eliz@gnu.org>, gdb-patches@sources.redhat.com
> 
> Thanks for all the guidence so far. Even though you have not attempted
> the observer approach, how do you feel about it? Is this something that
> you think could be accomplished with the current FSF GDB? Nick, Daniel
> and Eli, do you like this approach?

The record will show that I dislike using observers in core GDB
sources (i.e. in the sources released with official GDB
distributions).  But my opinions on this are usually voted down.

Re: RFC: MI output during program execution

[Bob Rossi]

> Remember I haven't done this with observers or events yet.  The way I  
> did it with hooks, the result of the hooks is gathered into the  
> "^done" or the other termination states for the command.  So for  
> instance, if you run gdb on itself, and do:

Hi Jim,

Thanks for all the guidence so far. Even though you have not attempted
the observer approach, how do you feel about it? Is this something that
you think could be accomplished with the current FSF GDB? Nick, Daniel
and Eli, do you like this approach? I'm sure I could find some time to 
get something going in this direction, with a little bit of thought.

Anyone else willing to work towards this solution?

I really like Daniel's idea of just alerting the user that something has
changed, instead of actually giving the user the data. For instance he
had,

   =breakpoint-changed,[bpnum="1",state="disabled"]
   =thread-changed,[thread="2"]

I might even prefer,
   =breakpoint-changed,thread-changed
which would then allow the FE to call -list-breakpoints or whatever if
they are interested.

This is very similar to how annotate=2 solved the problem for when
breakpoints changed. The only wierd issue that happened with this
approach is that the data breakpoint-changed was literally outputted
thousands and thousands of times in certain circumstances. (compiled
program with optimizations).

Thanks,
Bob Rossi

Re: RFC: MI output during program execution

[Daniel Jacobowitz]

On Tue, Aug 09, 2005 at 08:48:26PM -0400, Bob Rossi wrote:
> Here is another odd scenario, Jim, please give some info if you have
> experience in this area.
> 
> If you hit a breakpoint, and the observer starts to send you data, does
> it 
>    - send all the state data in one async response, in the same response as
>      the async MI command that says *stopped?
>    - send all the state data in one async response, in a different response 
>      as the async MI command that says *stopped?
>    - send all the state data, each in different async response's, in a 
>      different response as the async MI command that says *stopped?
> 
> This may seem unimportant, however I believe it could be marginally
> important. For instance, does the front end have to wait for the async
> observer response before it can do anything else?

I can't speak for what Apple's done, but it seems natural to me like
#3.  "state data" isn't a great term for this; they're notifications of
things, as they happen.  So it seems to me that you'd want something
like (forgive my syntax, don't take this literally!  I don't speak MI
at the moment):

=breakpoint-changed,[bpnum="1",state="disabled"]
=thread-changed,[thread="2"]

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: RFC: MI output during program execution

[Jim Ingham]

On Aug 9, 2005, at 5:48 PM, Bob Rossi wrote:

> On Tue, Aug 09, 2005 at 08:41:28PM -0400, Daniel Jacobowitz wrote:
>
>> On Tue, Aug 09, 2005 at 06:34:21PM -0400, Bob Rossi wrote:
>>
>>> However, in the meantime, I think it's possible to query the  
>>> state of
>>> GDB at any moment. So, if you allow the user to enter a command via
>>> -interpreter-exec console, you could then follow that command up  
>>> with
>>> other MI commands to sync the state of GDB with the state of the FE.
>>>
>>
>> But we haven't got all the relevant query commands, I think.  And I
>> haven't a clue what the full set would be.  Rather than adding them,
>> investing effort in getting the async approach going makes more sense
>> to me.
>>
>
> I agree. However, getting the observer approach up and running,  
> will in
> a way, define the full set.
>
>
>> As Jim's pointed out, you can need this any time you hit a  
>> breakpoint,
>> if the user has set commands on it.  Keeping track of this in the  
>> FE is
>> going to be tricky.  Also, if you're presenting a real console window
>> and you have to do a half-dozen queries after every command to  
>> keep the
>> UI up to date, that's probably going to be visibly slow.
>>
>
> Here is another odd scenario, Jim, please give some info if you have
> experience in this area.
>
> If you hit a breakpoint, and the observer starts to send you data,  
> does
> it
>    - send all the state data in one async response, in the same  
> response as
>      the async MI command that says *stopped?
>    - send all the state data in one async response, in a different  
> response
>      as the async MI command that says *stopped?
>    - send all the state data, each in different async response's, in a
>      different response as the async MI command that says *stopped?
>
> This may seem unimportant, however I believe it could be marginally
> important. For instance, does the front end have to wait for the async
> observer response before it can do anything else?

Remember I haven't done this with observers or events yet.  The way I  
did it with hooks, the result of the hooks is gathered into the  
"^done" or the other termination states for the command.  So for  
instance, if you run gdb on itself, and do:

(top-gdb) commands 3
Type commands for when breakpoint 3 is hit, one per line.
End with a line saying just "end".
 >print argc
 >up
 >break decode_line_1
 >continue
 >end
(top-gdb) set interpreter mi
-exec-run
*stopped,reason="breakpoint-hit",commands="yes",bkptno="3",thread-id="1"
~"$1 = 15"
~"\n"
~"#1  0x0003c4d0 in do_catch_errors (uiout=0x337618, data=0xbffff0f0)  
at ../../gdb/src/gdb/top.c:577\n"
~"577\t  return args->func (args->func_args);\n"
~"Breakpoint 4 at 0x8237c: file ../../gdb/src/gdb/linespec.c, line  
735.\n"
~"Continuing.\n"
^continuing
*started,MI_HOOK_RESULT= 
{HOOK_TYPE="frame_changed",frame="1"},MI_HOOK_RESULT= 
{HOOK_TYPE="breakpoint_create",bkpt= 
{number="4",type="breakpoint",disp="keep",enabled="y",addr="0x0008237c", 
func="decode_line_1",file="../../gdb/src/gdb/ 
linespec.c",line="735",shlib="/Volumes/ThePlayground/Users/jingham/ 
Work/gdb-sources/tot-shlib-experiment/build/gdb/ 
gdb",times="0"}},reason="breakpoint-command"
GNU gdb 2004-03-03-cvs (Thu Jul 28 18:14:44 GMT 2005)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and  
you are
welcome to change it and/or distribute copies of it under certain  
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for  
details.
This GDB was configured as "powerpc-apple-darwin8.1.0".
Setting up the environment for debugging gdb.
*stopped,reason="breakpoint-hit",commands="no",bkptno="4",thread-id="1"

So it's sort of like your third option, except it sends it as part of  
the message that tells you the breakpoint command handling is done.   
If the breakpoint had not done a continue, you would see:

=breakpoint-command-completed,MI_HOOK_RESULT= 
{HOOK_TYPE="frame_changed",frame="1"},MI_HOOK_RESULT= 
{HOOK_TYPE="breakpoint_create",bkpt= 
{number="4",type="breakpoint",disp="keep",enabled="y",addr="0x0008237c", 
func="decode_line_1",file="../../gdb/src/gdb/ 
linespec.c",line="735",shlib="/Volumes/ThePlayground/Users/jingham/ 
Work/gdb-sources/tot-shlib-experiment/build/gdb/gdb",times="0"}}

It might make more sense to have the "*started" be an "=started"  
message, I'm not sure why I made it a "*", I guess by analogy with  
the "*stopped"...

Jim

>
> Thanks,
> Bob Rossi
>

Re: RFC: MI output during program execution

[Daniel Jacobowitz]

On Tue, Aug 09, 2005 at 05:48:18PM -0700, Jim Ingham wrote:
> I agree, and it was filed as one by one of our users here...  I  
> looked a bit into what it would take to fix it and it was not  
> pretty.   Particularly for breakpoint commands, where it looked like  
> it would require some serious surgery.

Yes, exactly.  It requires an overhaul of the way we handle "what is
the inferior doing", "what is the inferior supposed to be doing", and
"what did the user ask us to do".

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: RFC: MI output during program execution

[Bob Rossi]

On Tue, Aug 09, 2005 at 08:41:28PM -0400, Daniel Jacobowitz wrote:
> On Tue, Aug 09, 2005 at 06:34:21PM -0400, Bob Rossi wrote:
> > However, in the meantime, I think it's possible to query the state of
> > GDB at any moment. So, if you allow the user to enter a command via
> > -interpreter-exec console, you could then follow that command up with
> > other MI commands to sync the state of GDB with the state of the FE.
> 
> But we haven't got all the relevant query commands, I think.  And I
> haven't a clue what the full set would be.  Rather than adding them,
> investing effort in getting the async approach going makes more sense
> to me.

I agree. However, getting the observer approach up and running, will in
a way, define the full set.

> As Jim's pointed out, you can need this any time you hit a breakpoint,
> if the user has set commands on it.  Keeping track of this in the FE is
> going to be tricky.  Also, if you're presenting a real console window
> and you have to do a half-dozen queries after every command to keep the
> UI up to date, that's probably going to be visibly slow.

Here is another odd scenario, Jim, please give some info if you have
experience in this area.

If you hit a breakpoint, and the observer starts to send you data, does
it 
   - send all the state data in one async response, in the same response as
     the async MI command that says *stopped?
   - send all the state data in one async response, in a different response 
     as the async MI command that says *stopped?
   - send all the state data, each in different async response's, in a 
     different response as the async MI command that says *stopped?

This may seem unimportant, however I believe it could be marginally
important. For instance, does the front end have to wait for the async
observer response before it can do anything else?

Thanks,
Bob Rossi

Re: RFC: MI output during program execution

[Daniel Jacobowitz]

On Tue, Aug 09, 2005 at 11:34:34AM -0700, Jim Ingham wrote:
> >How does -interpreter-exec console work in the case when the user
> >executes a command, that makes up several other commands?
> >
> >define mess_with_mi_people
> >   b main
> >   r
> >   n
> >   n
> >end
> >
> >I don't think this case would currently work as expected. Would it?
> 
> Remember that only one "run the target" command is allowed in a CLI  
> define.  All the others are ignored.

This is true (and documented, I think), but I still consider it a bug. 
It's just a particularly rotten one.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: RFC: MI output during program execution

[Jim Ingham]

On Aug 9, 2005, at 5:42 PM, Daniel Jacobowitz wrote:

> On Tue, Aug 09, 2005 at 11:34:34AM -0700, Jim Ingham wrote:
>
>>> How does -interpreter-exec console work in the case when the user
>>> executes a command, that makes up several other commands?
>>>
>>> define mess_with_mi_people
>>>   b main
>>>   r
>>>   n
>>>   n
>>> end
>>>
>>> I don't think this case would currently work as expected. Would it?
>>>
>>
>> Remember that only one "run the target" command is allowed in a CLI
>> define.  All the others are ignored.
>>
>
> This is true (and documented, I think), but I still consider it a bug.
> It's just a particularly rotten one.

I agree, and it was filed as one by one of our users here...  I  
looked a bit into what it would take to fix it and it was not  
pretty.   Particularly for breakpoint commands, where it looked like  
it would require some serious surgery.

Jim

Re: RFC: MI output during program execution

[Daniel Jacobowitz]

On Tue, Aug 09, 2005 at 06:34:21PM -0400, Bob Rossi wrote:
> However, in the meantime, I think it's possible to query the state of
> GDB at any moment. So, if you allow the user to enter a command via
> -interpreter-exec console, you could then follow that command up with
> other MI commands to sync the state of GDB with the state of the FE.

But we haven't got all the relevant query commands, I think.  And I
haven't a clue what the full set would be.  Rather than adding them,
investing effort in getting the async approach going makes more sense
to me.

As Jim's pointed out, you can need this any time you hit a breakpoint,
if the user has set commands on it.  Keeping track of this in the FE is
going to be tricky.  Also, if you're presenting a real console window
and you have to do a half-dozen queries after every command to keep the
UI up to date, that's probably going to be visibly slow.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: RFC: MI output during program execution

[Bob Rossi]

On Tue, Aug 09, 2005 at 10:27:34PM +0300, Eli Zaretskii wrote:
> > Date: Tue, 9 Aug 2005 14:13:11 -0400
> > From: Bob Rossi <bob@brasko.net>
> > Cc: Jim Ingham <jingham@apple.com>, gdb-patches@sources.redhat.com
> > 
> > > I thought we wanted to have _both_ CLI and MI style response in this
> > > case: the CLI response to display in the command buffer, the MI
> > > response to be caught by the front end in order to change the display
> > > in other windows.  Am I missing something?
> > 
> > Yes, this sounds nice to me. Currently, querying GDB/MI's state, via an
> > MI function allows this, without any modifications to GDB/MI. 
> 
> How would the FE know that it needs to query the state?  Isn't that
> the problem?

Eli, don't get me wrong. I fully support the observer approach,
especially from what Jim has said.

However, in the meantime, I think it's possible to query the state of
GDB at any moment. So, if you allow the user to enter a command via
-interpreter-exec console, you could then follow that command up with
other MI commands to sync the state of GDB with the state of the FE.

The problem is, commands like "are you still running?" defiantly carry a
race condition along with them.

Bob Rossi

Re: RFC: MI output during program execution

[Eli Zaretskii]

> Date: Tue, 9 Aug 2005 14:13:11 -0400
> From: Bob Rossi <bob@brasko.net>
> Cc: Jim Ingham <jingham@apple.com>, gdb-patches@sources.redhat.com
> 
> > I thought we wanted to have _both_ CLI and MI style response in this
> > case: the CLI response to display in the command buffer, the MI
> > response to be caught by the front end in order to change the display
> > in other windows.  Am I missing something?
> 
> Yes, this sounds nice to me. Currently, querying GDB/MI's state, via an
> MI function allows this, without any modifications to GDB/MI. 

How would the FE know that it needs to query the state?  Isn't that
the problem?

Re: RFC: MI output during program execution

[Jim Ingham]

On Aug 9, 2005, at 11:23 AM, Bob Rossi wrote:

> On Tue, Aug 09, 2005 at 10:59:25AM -0700, Jim Ingham wrote:
>
>> The front end needs to know if a CLI command executed via "-
>> interpreter-exec console" changed the current thread or frame - so it
>> can update the UI accordingly.  Or if it started the target running.
>> Or if it added a breakpoint.
>>
>> All these things could be queried from existing commands in the MI,
>> but that's pretty inconvenient and inefficient.  It's much easier to
>> code up the UI if gdb tells it asynchronously about these things.
>>
>
> OK, well then I completly agree that observers would be a very nice  
> way
> to solve this problem. When an internal MI state changes, it should
> alert the FE if the FE requested such knowledge. This is of course, an
> asyncronous approach as far as the FE is concerned. If the FE needs  
> this
> information now, it can simply poll GDB for this information.
>
> Also, I'm not convinced it would be inefficient to query GDB for the
> required information, especially if a new MI command was added to GDB
> that returned the current state of GDB. (frame,thread,file).

"Run over all state and see what changed" is a pain compared to "tell  
me when something changes".  If the former were hard to code up for  
some reason, I guess you could go for the latter, but it didn't take  
all that much thought to get this working...

>
> How does -interpreter-exec console work in the case when the user
> executes a command, that makes up several other commands?
>
> define mess_with_mi_people
>    b main
>    r
>    n
>    n
> end
>
> I don't think this case would currently work as expected. Would it?

Remember that only one "run the target" command is allowed in a CLI  
define.  All the others are ignored.

But anyway, in our setup, the UI would get notification that a  
breakpoint was set, and then that the target continued.

A harder one to handle is:

define really_mess_with_people
      break function_that_gets_hit_alot
      commands $bpnum
          print someInterestingVariable
          continue
      end
      r
end

because then you are going to get the breakpoint notification, then  
the run notification, then the breakpoint hit, at which point the  
target is going to start again, etc...  I don't see how you really  
solve this one with the UI polling for state.  But with the hooks and  
just a little bit of judicious trickery (we added a "breakpoint  
commands running" and "breakpoint commands done running" events so  
the UI would know to hold off doing it's "breakpoint hit handling"  
till the commands were done) we have this one working as well.

Jim

>
> Thanks,
> Bob Rossi
>

Re: RFC: MI output during program execution

[Bob Rossi]

On Tue, Aug 09, 2005 at 09:08:56PM +0300, Eli Zaretskii wrote:
> > From: Jim Ingham <jingham@apple.com>
> > Date: Tue, 9 Aug 2005 10:07:43 -0700
> > 
> > You don't want to run ALL cli commands through the mi command  
> > equivalents because then the output would come out in mi form, not  
> > cli form.
> 
> I thought we wanted to have _both_ CLI and MI style response in this
> case: the CLI response to display in the command buffer, the MI
> response to be caught by the front end in order to change the display
> in other windows.  Am I missing something?

Yes, this sounds nice to me. Currently, querying GDB/MI's state, via an
MI function allows this, without any modifications to GDB/MI. 

Is there any downside to this approach besides possible inefficiency?

Bob Rossi

Re: RFC: MI output during program execution

[Bob Rossi]

On Tue, Aug 09, 2005 at 10:59:25AM -0700, Jim Ingham wrote:
> The front end needs to know if a CLI command executed via "- 
> interpreter-exec console" changed the current thread or frame - so it  
> can update the UI accordingly.  Or if it started the target running.   
> Or if it added a breakpoint.
> 
> All these things could be queried from existing commands in the MI,  
> but that's pretty inconvenient and inefficient.  It's much easier to  
> code up the UI if gdb tells it asynchronously about these things.

OK, well then I completly agree that observers would be a very nice way
to solve this problem. When an internal MI state changes, it should
alert the FE if the FE requested such knowledge. This is of course, an
asyncronous approach as far as the FE is concerned. If the FE needs this
information now, it can simply poll GDB for this information.

Also, I'm not convinced it would be inefficient to query GDB for the
required information, especially if a new MI command was added to GDB
that returned the current state of GDB. (frame,thread,file). 

How does -interpreter-exec console work in the case when the user
executes a command, that makes up several other commands?

define mess_with_mi_people
   b main
   r
   n
   n
end

I don't think this case would currently work as expected. Would it?

Thanks,
Bob Rossi

Re: RFC: MI output during program execution

[Eli Zaretskii]

> From: Jim Ingham <jingham@apple.com>
> Date: Tue, 9 Aug 2005 10:07:43 -0700
> 
> You don't want to run ALL cli commands through the mi command  
> equivalents because then the output would come out in mi form, not  
> cli form.

I thought we wanted to have _both_ CLI and MI style response in this
case: the CLI response to display in the command buffer, the MI
response to be caught by the front end in order to change the display
in other windows.  Am I missing something?

Re: RFC: MI output during program execution

[Jim Ingham]

The front end needs to know if a CLI command executed via "- 
interpreter-exec console" changed the current thread or frame - so it  
can update the UI accordingly.  Or if it started the target running.   
Or if it added a breakpoint.

All these things could be queried from existing commands in the MI,  
but that's pretty inconvenient and inefficient.  It's much easier to  
code up the UI if gdb tells it asynchronously about these things.

Jim

On Aug 9, 2005, at 10:51 AM, Bob Rossi wrote:

>> But as I said in my previous note, I think a better solution is to
>> use hooks/observers/events or whatever to allow the MI to be informed
>> about things it needs to know about "behind the back" of the CLI
>> that's running the command.
>>
>
> Could you please give a quick example of something "the FE needs to  
> know
> about?" Would there be a default way to get all the things the FE
> cares about? Is it as easy as making a new MI command
>    -mi-get-state
> which would output a list of items the FE cares about?
>
> Thanks,
> Bob Rossi
>

Re: RFC: MI output during program execution

[Bob Rossi]

> But as I said in my previous note, I think a better solution is to  
> use hooks/observers/events or whatever to allow the MI to be informed  
> about things it needs to know about "behind the back" of the CLI  
> that's running the command.  

Could you please give a quick example of something "the FE needs to know
about?" Would there be a default way to get all the things the FE
cares about? Is it as easy as making a new MI command
   -mi-get-state
which would output a list of items the FE cares about?

Thanks,
Bob Rossi

Re: RFC: MI output during program execution

[Nick Roberts]

 > I'm a bit nervous about this literal testing of certain commands: why
 > not allow _any_ CLI commands to be supported in this way?  I
 > understand that you were trying to mention every command that runs the
 > inferior, but the implication is that we will need to remember to add
 > to this list any new command that has similar effects.  That sounds
 > like a PITA; could a more general solution be devised?

Indeed.  I missed out "continue" for a start.  Not all the CLI commands have
direct MI counterparts.  For commands that run the inferior the correspondence
is particular clear e.g.

   enum mi_cmd_result
   mi_cmd_exec_run (char *args, int from_tty)
   {
     /* FIXME: Should call a libgdb function, not a cli wrapper */
     return mi_execute_async_cli_command ("run", args, from_tty);
  }

i.e  they are just wrappers for the CLI command.

 > But I'm afraid that I'm somehow missing something, so could you please
 > elaborate on the design of the solution you propose?

It's just another fix and not a general solution.  Reading the comments for MI
there are already many such fixes (mi_execute_async_cli_command is an
example).  That doesn't justify further fixes, of course, and something more
general would clearly be better but beyond my current scope.

Nick

Re: RFC: MI output during program execution

[Nick Roberts]

 >             ...And I like it better than Nick's method of mocking up  
 > certain commands in interpreter-exec.  It seems better to specify  
 > "what you want to be told about" when one interpreter invokes  
 > another, rather than trying to guess which commands might do  
 > something you might want to know about.

I agree completely, but you don't appear to be offering to merge your
method into FSF GDB.  I am just suggesting that my method might be
better than the current behaviour.

Nick

Re: RFC: MI output during program execution

[Jim Ingham]

Eli,

You don't want to run ALL cli commands through the mi command  
equivalents because then the output would come out in mi form, not  
cli form.  You really want to try to maintain the fidelity of the  
original CLI command even when running them under the MI, or the  
user's experience with the console will be disconcerting.  I think  
that's why Nick only grabbed the ones he wants to get information from.

But as I said in my previous note, I think a better solution is to  
use hooks/observers/events or whatever to allow the MI to be informed  
about things it needs to know about "behind the back" of the CLI  
that's running the command.  This is pretty easy to do - at least  
with hooks it is, I haven't converted our code over to observers -  
and means you don't need to go command by command, which would be a  
PITA indeed, and as I said would lose with user-defined commands in  
any case...

Jim


On Aug 9, 2005, at 9:37 AM, gdb-patches-digest- 
help@sources.redhat.com wrote:

> I'm a bit nervous about this literal testing of certain commands: why
> not allow _any_ CLI commands to be supported in this way?  I
> understand that you were trying to mention every command that runs the
> inferior, but the implication is that we will need to remember to add
> to this list any new command that has similar effects.  That sounds
> like a PITA; could a more general solution be devised?
>
> But I'm afraid that I'm somehow missing something, so could you please
> elaborate on the design of the solution you propose?
>
>
>

Re: RFC: MI output during program execution

[Eli Zaretskii]

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Mon, 8 Aug 2005 16:20:43 +1200
> 
> --- 241,288 ----
>            and then set it back to 0 when we are done. */
>         sync_execution = 1;
>         {
> ! 	struct gdb_exception e;
> ! 	int flag = 0;
> ! 
> ! 	if (strcmp (argv[0], "console") == 0)
> ! 	  /* Stick with MI for commands which run the inferior. */
> ! 	  {
> ! 	    struct cmd_list_element *c;
> ! 	    extern struct cmd_list_element *cmdlist;
> ! 	    char *token, *cp;
> ! 
> ! 	    flag = 1;
> ! 	    cp = xstrdup (argv[i]);
> ! 	    c = lookup_cmd (&cp, cmdlist, "", 0, 0);
> ! 	    if (strcmp (c->name, "run") == 0)
> ! 	      mi_cmd_exec_run (cp, 0);
> ! 	    else if (strcmp (c->name, "next") == 0)
> ! 	      mi_cmd_exec_next (cp, 0);
> ! 	    else if (strcmp (c->name, "nexti") == 0)
> ! 	      mi_cmd_exec_next_instruction (cp, 0);
> ! 	    else if (strcmp (c->name, "step") == 0)
> ! 	      mi_cmd_exec_step (cp, 0);
> ! 	    else if (strcmp (c->name, "stepi") == 0)
> ! 	      mi_cmd_exec_step_instruction (cp, 0);
> ! 	    else if (strcmp (c->name, "finish") == 0)
> ! 	      mi_cmd_exec_finish (cp, 0);
> ! 	    else if (strcmp (c->name, "until") == 0)
> ! 	      mi_cmd_exec_until (cp, 0);
> ! 	    else if (strcmp (c->name, "return") == 0)
> ! 	      mi_cmd_exec_return (cp, 0);
> ! 	    else
> ! 	      flag = 0;

I'm a bit nervous about this literal testing of certain commands: why
not allow _any_ CLI commands to be supported in this way?  I
understand that you were trying to mention every command that runs the
inferior, but the implication is that we will need to remember to add
to this list any new command that has similar effects.  That sounds
like a PITA; could a more general solution be devised?

But I'm afraid that I'm somehow missing something, so could you please
elaborate on the design of the solution you propose?

Re: RFC: MI output during program execution

[Jim Ingham]

First off, "console-quoted" has a less grand  purpose than Nick  
thinks...  I added "console-quoted", because in the version of the  
interpreter code that I maintain in the Apple sources the console  
interpreter really is the CLI console interpreter, regardless of  
whether you are running it from the MI or not.  That is because I  
wanted to be able to really switch interpreters, not just fake the  
CLI under the covers of the MI - which is what Keith & Elena's  
version of the interpreter code does.  But this means that for the  
"console" interpreter, you get raw console output, not quoted nicely  
for consumption by the GUI.  So we needed a version of console to run  
from the MI that did the nice quoting.  Other than that, "console"  
and "console-quoted" are identical.

About Nick's patch.  We achieve the same result, but with a different  
method.  What I do is whenever I run a CLI command with the  
mi_cmd_interpreter_exec,  I install a bunch of notify hooks - the  
code to look at is mi_insert_notify_hooks.  These give us a way to  
funnel notifications from "behind the CLI's back".

We get a bunch of notifications this way, including breakpoint set,  
frame changed, etc...  Right now, I think most of the hook stuff got  
ripped out of the FSF gdb in favor of events^H^H^H^H^H^Hobservers.   
Someday when I have some spare time I need to go look at the  
observers, and see if I can get them to do the same thing I need the  
hooks to do.  One of the weaknesses of the hooks is they don't store  
data so I have to squirrel the mi interpreter the hook is for off  
into a global - which is unclean.  Maybe this sort of thing will be  
better if the hooking method is more advanced.

Anyway, this model is a sort of "on demand" way of implementing  
Daniel's notion of "keeping all the interpreters open at the same  
time".  Namely, when interpreter A relinquishes control to  
interpreter B, it registers for all the things it would like to be  
informed of before it does so.  It has the virtue of not having to  
multiplex all the information gdb generates down multiple channels.   
You just selectively funnel off the pieces you are interested in.  As  
long as the hooks (or whatever they are now with observers...) are  
correctly maintained, this is pretty easy to make work.

In general, there's only one interpreter "in charge" at a time.  So I  
think this model of "inserting your listeners when you give up  
charge" is not too bad.  It has proved pretty workable for what we  
do, anyway.  And I like it better than Nick's method of mocking up  
certain commands in interpreter-exec.  It seems better to specify  
"what you want to be told about" when one interpreter invokes  
another, rather than trying to guess which commands might do  
something you might want to know about.  Unless you disallow "define"  
on the CLI side, you're always going to lose this game anyway...

Note, there are some tricky bits to this model.  For instance, if you  
are running the MI, and use "-interpreter-exec console" to set  
commands on a breakpoint, those commands should be run with the CLI  
interpreter when you hit the breakpoint.  But that means that some  
actions - in this case hitting a breakpoint as part of the completion  
to an "-exec-run" command - can force you over to the CLI interpreter  
for a little while.

There's a bit of trickery in our sources to handle this.  I didn't do  
it "right" - where "right" would be to abstract the notion of a  
breakpoint command out of the CLI and do some hand-off between the  
current interpreter and the one in charge of the breakpoint command  
code.  For our purposes, the CLI is the only thing that gets to  
register breakpoint commands - the GUI can react in a scripted manner  
to breakpoint hits on its own, so there was no need to add this  
complexity.

The most current version of our sources is available in tar.gz form at:

http://www.opensource.apple.com/darwinsource/tarballs/other/ 
gdb-384.tar.gz

I am pretty sure the CVS repository is up to date with this as well  
(some projects require an ADC membership, but gdb & friends have  
anonymous access).  See

http://developer.apple.com/darwin/tools/cvs/howto.html

for more details.

This code is based on a merge that's almost a year old now.  Stan &  
Klee are working away at a more recent merge - we're pretty sure the  
patient will survive, but it's definitely not ambulatory yet...

Jim








On Aug 8, 2005, at 6:05 AM, Daniel Jacobowitz wrote:

> On Mon, Aug 08, 2005 at 04:20:43PM +1200, Nick Roberts wrote:
>
>>
>> Although Emacs will increasingly use GDB/MI to interact with GDB,  
>> the GUD
>> buffer will always require the use of CLI commands.  These are  
>> executed via
>> "-interpreter-exec console" that Jim Ingham/Apple contributed.  In  
>> general
>> this isn't a problem, but CLI commands which start the inferior  
>> e.g run, next,
>> finish etc do not tell Emacs when the inferior is executing (do  
>> not output
>> ^running) and in some cases generate inappropriate output such as  
>> the current
>> source line as CLI output.  I would like to change the output of  
>> these
>> commands to that of their MI counterparts.  I think that Apple  
>> have added a
>> separate interpreter (console-quoted) for this kind of thing.  The  
>> patch below
>> reflects my more modest resources and limited knowledge and seems  
>> to do the
>> kind of thing that Emacs needs.  It doesn't change direct use of  
>> MI commands,
>> just the behaviour of a subset of CLI commands invoked the the MI  
>> interpreter:
>>
>
> Fortunately, we've got access to all these bright folks at Apple.
> Does the console-quoted approach sound good to you?  Jim, is a recent
> snapshot of the code for it available?
>
> The following has no frontend implementation experience behind it
> whatsoever.  However, it's relevant from my few tries at adding full
> scripting support to GDB.  What I'd like to see is a way to keep
> multiple interpreters open at the same time.  Then, have one of them
> accepting input at a time, and receiving informative output, but  
> all of
> them receiving some kinds of output.  For instance, all open MI
> channels could receive a notice on breakpoint deletion, no matter  
> where
> the request came from.  If the console starts GDB running in this  
> case,
> the MI interpreter would still get a ^running.
>
> -- 
> Daniel Jacobowitz
> CodeSourcery, LLC
>

Re: RFC: MI output during program execution

[Daniel Jacobowitz]

On Mon, Aug 08, 2005 at 04:20:43PM +1200, Nick Roberts wrote:
> 
> Although Emacs will increasingly use GDB/MI to interact with GDB, the GUD
> buffer will always require the use of CLI commands.  These are executed via
> "-interpreter-exec console" that Jim Ingham/Apple contributed.  In general
> this isn't a problem, but CLI commands which start the inferior e.g run, next,
> finish etc do not tell Emacs when the inferior is executing (do not output
> ^running) and in some cases generate inappropriate output such as the current
> source line as CLI output.  I would like to change the output of these
> commands to that of their MI counterparts.  I think that Apple have added a
> separate interpreter (console-quoted) for this kind of thing.  The patch below
> reflects my more modest resources and limited knowledge and seems to do the
> kind of thing that Emacs needs.  It doesn't change direct use of MI commands,
> just the behaviour of a subset of CLI commands invoked the the MI interpreter:

Fortunately, we've got access to all these bright folks at Apple. 
Does the console-quoted approach sound good to you?  Jim, is a recent
snapshot of the code for it available?

The following has no frontend implementation experience behind it
whatsoever.  However, it's relevant from my few tries at adding full
scripting support to GDB.  What I'd like to see is a way to keep
multiple interpreters open at the same time.  Then, have one of them
accepting input at a time, and receiving informative output, but all of
them receiving some kinds of output.  For instance, all open MI
channels could receive a notice on breakpoint deletion, no matter where
the request came from.  If the console starts GDB running in this case,
the MI interpreter would still get a ^running.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

RFC: MI output during program execution

[Nick Roberts]

Although Emacs will increasingly use GDB/MI to interact with GDB, the GUD
buffer will always require the use of CLI commands.  These are executed via
"-interpreter-exec console" that Jim Ingham/Apple contributed.  In general
this isn't a problem, but CLI commands which start the inferior e.g run, next,
finish etc do not tell Emacs when the inferior is executing (do not output
^running) and in some cases generate inappropriate output such as the current
source line as CLI output.  I would like to change the output of these
commands to that of their MI counterparts.  I think that Apple have added a
separate interpreter (console-quoted) for this kind of thing.  The patch below
reflects my more modest resources and limited knowledge and seems to do the
kind of thing that Emacs needs.  It doesn't change direct use of MI commands,
just the behaviour of a subset of CLI commands invoked the the MI interpreter:

-exec-next
^running
(gdb) 
*stopped,reason="end-stepping-range",thread-id="0",frame={addr="0x080484ef",func="main",args=[{name="argc",value="1"},{name="argv",value="0xbffff794"}],file="myprog.c",fullname="/home/nick/myprog.c",line="46"}
(gdb) 

-interpreter-exec console next
^running
(gdb) 
*stopped,reason="end-stepping-range",thread-id="0",frame={addr="0x0804851f",func="main",args=[{name="argc",value="1"},{name="argv",value="0xbffff794"}],file="myprog.c",fullname="/home/nick/myprog.c",line="47"}
^done
(gdb) 

Note that the latter generates an extra ^done as the MI command
-interpreter-exec completes.  I'm not asking for approval at this stage, but
any feedback would be most welcome.

Nick



*** mi/mi-interp.c.~1.15.~	2005-08-01 10:45:28.000000000 +1200
--- mi/mi-interp.c	2005-08-08 11:10:08.000000000 +1200
***************
*** 33,38 ****
--- 33,40 ----
  #include "mi-out.h"
  #include "mi-console.h"
  
+ #include "cli/cli-decode.h"
+ 
  struct mi_interp
  {
    /* MI's output channels */
*************** mi_cmd_interpreter_exec (char *command, 
*** 239,250 ****
           and then set it back to 0 when we are done. */
        sync_execution = 1;
        {
! 	struct gdb_exception e = interp_exec (interp_to_use, argv[i]);
! 	if (e.reason < 0)
  	  {
! 	    mi_error_message = xstrdup (e.message);
! 	    result = MI_CMD_ERROR;
! 	    break;
  	  }
        }
        xfree (buff);
--- 241,288 ----
           and then set it back to 0 when we are done. */
        sync_execution = 1;
        {
! 	struct gdb_exception e;
! 	int flag = 0;
! 
! 	if (strcmp (argv[0], "console") == 0)
! 	  /* Stick with MI for commands which run the inferior. */
! 	  {
! 	    struct cmd_list_element *c;
! 	    extern struct cmd_list_element *cmdlist;
! 	    char *token, *cp;
! 
! 	    flag = 1;
! 	    cp = xstrdup (argv[i]);
! 	    c = lookup_cmd (&cp, cmdlist, "", 0, 0);
! 	    if (strcmp (c->name, "run") == 0)
! 	      mi_cmd_exec_run (cp, 0);
! 	    else if (strcmp (c->name, "next") == 0)
! 	      mi_cmd_exec_next (cp, 0);
! 	    else if (strcmp (c->name, "nexti") == 0)
! 	      mi_cmd_exec_next_instruction (cp, 0);
! 	    else if (strcmp (c->name, "step") == 0)
! 	      mi_cmd_exec_step (cp, 0);
! 	    else if (strcmp (c->name, "stepi") == 0)
! 	      mi_cmd_exec_step_instruction (cp, 0);
! 	    else if (strcmp (c->name, "finish") == 0)
! 	      mi_cmd_exec_finish (cp, 0);
! 	    else if (strcmp (c->name, "until") == 0)
! 	      mi_cmd_exec_until (cp, 0);
! 	    else if (strcmp (c->name, "return") == 0)
! 	      mi_cmd_exec_return (cp, 0);
! 	    else
! 	      flag = 0;
! 	  }
! 
! 	if (!flag)
  	  {
! 	    e = interp_exec (interp_to_use, argv[i]);
! 	    if (e.reason < 0)
! 	      {
! 		mi_error_message = xstrdup (e.message);
! 		result = MI_CMD_ERROR;
! 		break;
! 	      }
  	  }
        }
        xfree (buff);