Calling inferior functions and MI notification

Calling inferior functions and MI notification

[Vladimir Prus]

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

Re: Calling inferior functions and MI notification

[Denis PILAT]

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

Re: Calling inferior functions and MI notification

[Daniel Jacobowitz]

On Thu, Mar 27, 2008 at 07:49:09PM +0300, Vladimir Prus wrote:
> 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?

I like #2 better than #1.  Maybe the default should depend on the MI
version?  We could add this to the list of changes in MI3.

-- 
Daniel Jacobowitz
CodeSourcery

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

Re: Calling inferior functions and MI notification

[Vladimir Prus]

Pawel Piech wrote:

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

Hello Pawel,

can you clarify what the 'reason' field should contain? I think that in
general, reporting the command that caused the run might be impossible.

- Volodya

Re: Calling inferior functions and MI notification

[Pawel Piech]

Vladimir Prus wrote:
> Pawel Piech wrote:
>
>   
>> 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.
>>     
>
> Hello Pawel,
>
> can you clarify what the 'reason' field should contain? I think that in
> general, reporting the command that caused the run might be impossible.
>
>   
Too bad, because that's what I had in mind....  Like I said, IDE's 
including Eclipse usually solve this problem on their own, though the 
solution is theoretically susceptible to a race condition in cases where 
multiple interfaces are used to interact with GDB simultaneously.
Cheers,
Pawel
> - Volodya
>
>
>   

Re: Calling inferior functions and MI notification

[Vladimir Prus]

Pawel Piech wrote:

> Vladimir Prus wrote:
>> Pawel Piech wrote:
>>
>>   
>>> 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.
>>>     
>>
>> Hello Pawel,
>>
>> can you clarify what the 'reason' field should contain? I think that in
>> general, reporting the command that caused the run might be impossible.
>>
>>   
> Too bad, because that's what I had in mind....  Like I said, IDE's
> including Eclipse usually solve this problem on their own, though the
> solution is theoretically susceptible to a race condition in cases where
> multiple interfaces are used to interact with GDB simultaneously.

In what cases associating "*running" with a command is important? You
still get "^running", so you know what the command started something.
The "*running" can be used to update the state of the threads in UI.

I'm actually thinking of making -thread-info report the operation that
each running thread executes, like "step" or "finish" -- when that
information is available.

- Volodya