This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Calling inferior functions and MI notification


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





Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]