Re: Calling inferior functions and MI notification

[Denis PILAT <denis dot pilat at st dot com>]

Hi Vladimir,

I think solution 2 is better since it will let Eclipse (or any FE) the 
possibility to handles "*running" as an Out Of Band Record, as then let 
the user knows that the program is running...
Moreover, when within Eclipse you hit a breakpoint in an inferior 
function call, it exits gdb so I think CDT needs to handle inf. calls in 
a better way, or gdb avoid stopping when it's an inferior function call.

Having these new notifications would help I guess, at least to warn the 
GUI about the execution of a command and avoid entering new execution 
command until it returns.

Did you post that to cdt mailing list ?
Denis

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