MI Development

MI Development

[Vladimir Prus]

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

Re: MI Development

[Vladimir Prus]

On Tuesday 04 September 2007 18:28:15 André Pönitz wrote:

> > 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
> > al type, using Apple's branch as reference.
> 
> Personally I think variable objects are not very well suited for C++ at all.
> Say, I want to display a "std::vector<int> x"in a frontend I usually do not
> want to show three pointers to some internal data. Instead I usually want
> to have  x[0]...x[x.size()-1] as children. This is doable with variable objects,
> but the result feels clumsy, and the "update" feature cannot really be
> used.

I think we can fix that. I'd imagine we can make gdb invoke a Python hook
on -var-list-children. That hook will compute values that correspond to vector
member and create variable objects out of those. There's some work on Python
scripting already; I'd hope this use case will be kept in mind.

There's extra problem is that MI is not prepared that the number of children
of a variable objects can change -- and it can change in case of a vector. We'd
need to fix that.
 
> > 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.
> 
> Yup. And there seems to be no way to reliably tell whether a (C++) variable has already been
> constructed.

This is indeed big problem, and I don't know if anybody's working on getting gcc to produce
accurate debug information for that.

- Volodya

Re: MI Development

[Nick Roberts]

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

With asynchronous operation, asynchronous CLI commands give the same MI output
that MI commands do.

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

I'm just focussing on C as problems with C++ are too great for me.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: MI Development

[Vladimir Prus]

On Wednesday 05 September 2007 09:30:52 Nick Roberts wrote:
>  > 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.
> 
> With asynchronous operation, asynchronous CLI commands give the same MI output
> that MI commands do.

Why would I want to enable asynchronous operation for that to work? The
default behaviour is just broken, so even if --async fixes that, we should not
require any switches to get non-broken behaviour.

- Volodya

Re: MI Development

[Nick Roberts]

 > > With asynchronous operation, asynchronous CLI commands give the same MI
 > > output that MI commands do.
 > 
 > Why would I want to enable asynchronous operation for that to work? The
 > default behaviour is just broken, so even if --async fixes that, we should
 > not require any switches to get non-broken behaviour.

My understanding is that currently GDB only operates synchronously (except
perhaps with remote targets).

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: MI Development

[Vladimir Prus]

On Wednesday 05 September 2007 10:29:17 Nick Roberts wrote:
>  > > With asynchronous operation, asynchronous CLI commands give the same MI
>  > > output that MI commands do.
>  > 
>  > Why would I want to enable asynchronous operation for that to work? The
>  > default behaviour is just broken, so even if --async fixes that, we should
>  > not require any switches to get non-broken behaviour.
> 
> My understanding is that currently GDB only operates synchronously (except
> perhaps with remote targets).

We're talking past each other, I'm afraid :-(

I'm saying that currently, "^running" is not output in cases where it definitely should,
and that should be fixed. It's not apparent to me why this fix is related to any asynchronous
operation, and if so, this should be fixed separately, and as soon as possible -- meaning
as soon as I personally find time for that. Do you disagree?

- Volodya

Re: MI Development

[Nick Roberts]

 > I'm saying that currently, "^running" is not output in cases where it
 > definitely should, and that should be fixed. It's not apparent to me why
 > this fix is related to any asynchronous operation, and if so, this should be
 > fixed separately, and as soon as possible -- meaning as soon as I personally
 > find time for that. Do you disagree?

I think a patch would be a good idea as it would provide something concrete on
which to focus our discussion.

-- 
Nick                                           http://www.inet.net.nz/~nickrob