MI Development

[Vladimir Prus <ghost@cs.msu.su>]

[-- Attachment #1: Type: text/plain, Size: 552 bytes --]


Hi,
it should come as no surprise that the MI interface, as currently 
implemented in gdb, is not ideal. From experience working on KDevelop,
I've created a list of issues with MI, which is attached to this email.

That's something I'm planning to work on during my "KDevelop time",
but it would be great to get some help:

	- If you think MI has some other import issues, let me know
	- If you, perhaps, would like to work on any of those issues,
	that will be even more appreciated -- just let me know so that
	we don't duplicate work.

- Volodya



[-- Attachment #2: MI Development.txt --]
[-- Type: text/plain, Size: 1716 bytes --]



MI Development

The GDB/MI interface as it is today has the following important problems.

Variable objects and RTTI
For C++, variable objects are not able to look at the real type of the object.
Only the static type is shown. We should be able to implement display of
real type, using Apple's branch as reference.

Pending breakpoints don't work
It is not possible to create a pending breakpoint using MI interfaces. Further, when a pending
breakpoint is resolved, the breakpoint number changes, and there's no MI notification for that. 
The second problem will be (accidentally) fixed by some upcoming CodeSourcery patches, but
the first one needs separate work.

CLI commands bypass MI
When a CLI command is issued, we don't see "^running". As result, frontend can easily think 
that gdb is waiting for commands while inferior is running.

Variable objects and scopes

Variable objects don't care much about C++ scopes. For example, it's not possible to
create a variable object for a given expression in particular scope, which makes it impossible
to accurately implement variable tooltips. Also, it's not possible to list all local variables in the
entire function, which requires extraordinary effort to display all local variables as the enter
scope and leave scope.


Change notification style
Generally, all commands that a frontend might want to issue at each step -- list of breakpoints,
list of threads, list frames, list of local variables -- should have a notification to match, which is
emitted whenever gdb thinks the result of those command can possibly change. Wit this,
the frontend won't have to automatically issue any commands after step -- if anything changes,
gdb will report that itself.