Calling inferior functions and MI notification

[Pawel Piech]

It would be helpful if *running event included a "reason" field.  IDE's 
ususally track the command they just sent to determine the reason for 
resume event, but as it's an out-of-band record there is a possibility 
of a race condition which could break the IDE assumption.
Cheers,
Pawel


Vladimir Prus wrote:
> Hello,
> presently, when a GDB command calls an inferior function, for
> example:
>
> 	-data-evaluate-expression foo()
>
> the MI frontend is not informed in any way. So, should the function
> get stuck, the user will not even understand that inferior is running,
> and will have hard time figuring that he should click the "interrupt"
> button, or whatever.
>
> Ideally, the output should be like this:
>
> 	(gdb) -data-evaluate-expression foo()
> 	*running,thread-id="1"
> 	*stopped
> 	^done,result="100"
>
> However, I believe that making such a change will immediately break both KDevelop
> and Eclipse CDT -- because whenever they see *stopped, a full refresh of everything
> is done. If any variable object involves function call, *stopped will be emitted
> again, and cause another refresh. At least, I cannot see anything protecting
> from that.
>
> So, we have two solutions:
> 1. Just don't emit those notification for inferior function calls.
> 2. Don't emit them by default. Provide a command to enable this new
> behaviour.
>
> Comments or better suggestions?
>
> - Volodya
>
>
>
>