This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: MI: type prefixes for values
On Friday 17 February 2006 17:10, Eli Zaretskii wrote:
> > From: Vladimir Prus <ghost@cs.msu.su>
> > Date: Fri, 17 Feb 2006 16:58:22 +0300
> > Cc: gdb@sources.redhat.com
> >
> > > > It's only avaiable in tooltip text for a variable. So far, no
> > > > complaints.
> > >
> > > I don't see how is this contrary to what GDB assumes. GDB passes the
> > > information to the front end; how the front end displays it, is
> > > entirely up to the front end.
> >
> > Because for display in variable tree, frontend prefers not to show any
> > type, and for display in varible tooltips, it prefers to show the type
> > after the value, not before.
>
> That's quite specific to that front end, right? We cannot possibly
> assume they all will behave like that.
Exactly. Then why format value in a specific way that suites some frontends,
but not others.
> > - The parsing of that value will have to be done by ad-hoc code, which is
> > contrary to MI-goal of being easily parsable.
>
> Why ad-hoc? if you have {}, parse it, if not, don't. Why is this
> simple rule hard for a parser?
Here's the relevant part from KDevelop:
if (*start == '{')
{
// Gdb uses '{' in two cases:
// - composites (arrays and structures)
// - pointers to functions. In this case type is
// enclosed in "{}". Not sure why it's so, as
// when printing pointer, type is in parenthesis.
if (type == typePointer)
{
// Looks like type in braces at the beginning. Strip it.
start = skipDelim(start, '{', '}');
}
else
{
// Looks like composite, strip the braces and return.
return QCString(start+1, end - start -1);
}
You see, if I strip everything {}-enclosed at the beginning of value, I'll
never show any structures. And how do I decide if the value is a pointer, or
structure? That code was written before me, and is 100 lines in size.
And the only way to reliably tell if a variable is a pointer or not is to
issue -var-type-info, which, according to you, is not necessary if there's {}
in the value. Or I might look after the closing brace and see if there's
anything there, which starts to look pretty hacky.
> > > Then perhaps we should add the type info to all arguments, instead of
> > > removing it from where it exists now.
> >
> > It might be good idea, but why don't add it as a separate field? I.e.
> > instead of
> >
> > ^done,value="(int *) 0x0"
> >
> > you'll get
> >
> > ^done,value="0x0",type="int *"
>
> Fine with me.
So, are patches to the effect of removing type from value, and moving it to a
separate field welcome?
- Volodya