Re: MI output command error

[Jim Ingham <jingham at apple dot com>]

Eli is right, gdb was changed to HAVE an event loop, which made  
handling async targets possible.  But then the target itself needed  
to be made asynchronous as well.  There is a remote async target  
already, though I don't know how well it works.  For a ptrace based  
target (most native targets) you need to have a separate thread to  
run wait4 which then communicates back to the event source through  
some kind of signal. For procfs, I bet it would be even easier, since  
then you could just make an event source for the various proc files  
you need to watch and add them to the general "select" call that also  
waits for command input.

We made this work (for a ptrace-like setup) on Mac OS X.  There were  
a bunch of little bugs we had to deal with (like breakpoint commands  
that can restart the target are a little tricky when you have an  
async target).  There was a bunch of fiddling necessary to make it  
stable, but it wasn't all that hard.  It certainly is useful from a  
GUI to be able to interrupt, and almost more important to be able to  
ask gdb "are you running the target or not?" which can help sync up  
the GUI if things get confused as they sometimes do...

Jim

On Mar 12, 2005, at 11:39 AM, gdb-digest-help@sources.redhat.com wrote:

> > From: Nick Roberts <nickrob@snap.net.nz>
> > Date: Sat, 12 Mar 2005 10:49:41 +1300
> > Cc: Dave Korn <dave.korn@artimi.com>,
> >     Karganov Konstantin <kostik@ispras.ru>, GDB  
> > <gdb@sources.redhat.com>
> >
> > > Lack of implementation.  No one's done the work.
> >
> > Thats understandable. However, given that MI was introduced in GDB  
> > 5.0, I
> > think there should be something in the manual explaining this as  
> > it seems to
> > create a lot of confusion. It needs to be written by someone who  
> > understands
> > the issue i.e not myself.
>
> I'm all for documenting this in some useful way, but I fail to see how
> could this be done.  Describing the async operation itself is already
> a big challenge, as the details are extremely confusing, unless you've
> read the code several times and have a good understanding of the
> underlying system calls (like `poll' and `select').  Differences
> between interpreters add another dimension of complexity to this.
>
> > I believe that operation is asynchronous with certain targets,
> > although I have never managed to create these conditions, even with
> > gdbserver over TCP.
>
> Actually, I think that the asynchronous operation is independent of
> the target.  The infrastructure for this is in event-loop.c, which is
> not specific to any target.
>
> The problem with implementing async operation with the CLI interface
> is, AFAIU, not its dependence on some target-specific feature, but
> rather the need to redesig the CLI front end to do something useful
> while waiting for a prolonged operation to run to completion.  For GUI
> front ends, such as those who use MI, it's clear what to do during
> that time, and the separate-process implementation makes it even
> easier to design.  By contrast, the CLI interface is part of the GDB
> process.
>
> I don't consider myself a specialist in these matters, so please take
> the above with a grain of salt (i.e., it might all be wrong ;-).