Re: MI: "^running" issues

[Jim Ingham <jingham@apple.com>]

We got the asynchronous mode working for the Mac OS X target in the  
Apple gdb sources.  It definitely took a bunch of work beyond what is  
in the current FSF sources to get all the details working (things like  
breakpoint commands that restart the target and command files and some  
other bits like that needed attending to...)  It wasn't deadly hard to  
do, though.

We use it mostly so that Xcode can query the target's state at any  
point - basically a backstop when it looks like maybe the UI and gdb  
have gotten out of sync.  That way you can always unambiguously get  
the tri-state answer - the target's stopped; the target's running;  
gdb's gone south.  This is actually pretty useful to have around,  
though in a perfect world would not be necessary...

We also use -exec-interrupt.  It's certainly true that you can achieve  
the same thing by sending ^C to the target, but it's much more regular  
to do everything you're doing with the target through the same control  
channel.  And of course, this moves to gdb the knowledge of any  
funniness with interrupting a running program - which is where it  
belongs.

Another stronger reason why async was originally done was the  
experience of merging gdb with Tcl/Tk for the Insight debugger.  One  
of the big reasons for the instability of that project is that when  
the target is running, gdb is blocked, so if you want to service other  
events - like window system events in the case of Insight - you've got  
no good way to do that.  We ended up having to run a timer and try to  
service events in the timer interrupt - a dubious practice at best.

It's possible to run the interpreter in a separate thread, and let it  
and gdb communicate through some side channel.  But most interpreters  
have some mechanism for handling events, and it is much cleaner to  
have gdb be just another event source.

I'm not sure that the current gdb event mechanism is clean enough for  
easy incorporation with <Insert your favorite command language>'s  
event loop now.  But that just means there's more design work to do.   
I still think this is a pretty worthwhile goal.

Jim



On Sep 5, 2007, at 11:41 AM, Vladimir Prus wrote:

> Eli Zaretskii wrote:
>
>>> From: Vladimir Prus <ghost@cs.msu.su>
>>> Date: Wed, 5 Sep 2007 09:38:45 +0400
>>> Cc: gdb@sources.redhat.com
>>>
>>>>>   - Killing the idea of async commands. It does not seem to be  
>>>>> very
>>>>>   useful
>>>>> at this point, so we might be better off ripping it and  
>>>>> implementing
>>>>> afresh later, when it's understood what they should be.
>>>>
>>>> I'm working in the opposite direction: trying to get GDB to work
>>>> asynchronously. I don't see the point of ripping out what is  
>>>> already
>>>> there.
>>>
>>> Then, can you please provide a specification of what  
>>> "asynchronously"
>>> means, and why it's good for users and frontends?
>>
>> Asynchronous execution means that some GDB commands can be run while
>> GDB waits for the target to stop.  It is good for users because you
>> can do something useful while you wait for the target to stop.
>
> Unfortunately, I never saw more concrete details. What commands are  
> actually
> meaningful to emit while target are running and are those commands  
> of big
> enough value to user to warrant extensive coding? Can interested  
> parties document
> those commands at GDB Wiki, or even in email?
>
> - Volodya
>
>