MI: type prefixes for values

MI: type prefixes for values

[Vladimir Prus]

Hi,

some time ago I've raised the question why MI output sometimes prefixes
variable values with it's type. For example:

   -data-evaluate-expression *p3
   ^done,value="{int (int)} 0xb7ee6e9c <__DTOR_END__+4>"
   (gdb)

(note the {int (int)} part). The part does not make sense for a GUI and must
be removed by a specially written code.

See:

   http://article.gmane.org/gmane.comp.gdb.devel/13477

In the end, I've inquired why such prefixes cannot be dropped:

  http://article.gmane.org/gmane.comp.gdb.devel/13539

I imagine it's a simple matter of wrapping some code in
"ui_output_is_mi_like_p". Can somebody comment on this proposal?

Also, I note that gdb is currently inconsitent even within itself:

    (gdb)
    -thread-select 2
    ^done,new-thread-id="2",frame={level="0",func="thread",
    args=[{name="p",value="0x0"}],..........
   (gdb)
   -stack-list-arguments 1 0 0
   ^done,stack-args=[frame={level="0",
   args=[{name="p",value="(void *) 0x0"}]}]

Note that first output has "0x0" as value of 'p', and the second has 
"(void *)0x0". 

So, can a clear decision be made if the type prefixes has a place in MI, or
should be removed?

Thanks,
Volodya

Re: MI: type prefixes for values

[Eli Zaretskii]

> From:  Vladimir Prus <ghost@cs.msu.su>
> Date:  Fri, 17 Feb 2006 12:08:32 +0300
> 
> some time ago I've raised the question why MI output sometimes prefixes
> variable values with it's type. For example:
> 
>    -data-evaluate-expression *p3
>    ^done,value="{int (int)} 0xb7ee6e9c <__DTOR_END__+4>"
>    (gdb)
> 
> (note the {int (int)} part). The part does not make sense for a GUI and must
> be removed by a specially written code.
> 
> See:
> 
>    http://article.gmane.org/gmane.comp.gdb.devel/13477

And you were answered in that thread that this prefix is to show you
the signature of a function to which p3 is a pointer.  That is, GDB is
telling you that p3 points to a function which accepts a single int
argument and returns an int.

> In the end, I've inquired why such prefixes cannot be dropped:
> 
>   http://article.gmane.org/gmane.comp.gdb.devel/13539

Are you saying that you don't want to show your users the fact that
the pointed object is a function?

> I imagine it's a simple matter of wrapping some code in
> "ui_output_is_mi_like_p". Can somebody comment on this proposal?

I think this will lose useful information.  So for now I object.

> Also, I note that gdb is currently inconsitent even within itself:
> 
>     (gdb)
>     -thread-select 2
>     ^done,new-thread-id="2",frame={level="0",func="thread",
>     args=[{name="p",value="0x0"}],..........
>    (gdb)
>    -stack-list-arguments 1 0 0
>    ^done,stack-args=[frame={level="0",
>    args=[{name="p",value="(void *) 0x0"}]}]
> 
> Note that first output has "0x0" as value of 'p', and the second has 
> "(void *)0x0". 

Also, the first one shows the func= part, the second doesn't.  Looks
like a bug to me: those two should both use the same code.

> So, can a clear decision be made if the type prefixes has a place in MI, or
> should be removed?

At least for functions, they convey useful information.

Re: MI: type prefixes for values

[Vladimir Prus]

On Friday 17 February 2006 13:22, Eli Zaretskii wrote:
> > From:  Vladimir Prus <ghost@cs.msu.su>
> > Date:  Fri, 17 Feb 2006 12:08:32 +0300
> >
> > some time ago I've raised the question why MI output sometimes prefixes
> > variable values with it's type. For example:
> >
> >    -data-evaluate-expression *p3
> >    ^done,value="{int (int)} 0xb7ee6e9c <__DTOR_END__+4>"
> >    (gdb)
> >
> > (note the {int (int)} part). The part does not make sense for a GUI and
> > must be removed by a specially written code.
> >
> > See:
> >
> >    http://article.gmane.org/gmane.comp.gdb.devel/13477
>
> And you were answered in that thread that this prefix is to show you
> the signature of a function to which p3 is a pointer.  That is, GDB is
> telling you that p3 points to a function which accepts a single int
> argument and returns an int.
>
> > In the end, I've inquired why such prefixes cannot be dropped:
> >
> >   http://article.gmane.org/gmane.comp.gdb.devel/13539
>
> Are you saying that you don't want to show your users the fact that
> the pointed object is a function?

At the very least, not in the way that gdb assumes. The type prefix is removed 
the from variable value shown to the user.

> > I imagine it's a simple matter of wrapping some code in
> > "ui_output_is_mi_like_p". Can somebody comment on this proposal?
>
> I think this will lose useful information.  So for now I object.

You can get the type information via the -var-info-type, which is more formal 
way to get this information. A frontend is in position to call -var-info-type 
as needed and make UI presentation decision based on that as it likes.

With mandatory "{}" prefix frontend should make special efforts to remove that 
part, which is not formally documented. 

> > Also, I note that gdb is currently inconsitent even within itself:
> >
> >     (gdb)
> >     -thread-select 2
> >     ^done,new-thread-id="2",frame={level="0",func="thread",
> >     args=[{name="p",value="0x0"}],..........
> >    (gdb)
> >    -stack-list-arguments 1 0 0
> >    ^done,stack-args=[frame={level="0",
> >    args=[{name="p",value="(void *) 0x0"}]}]
> >
> > Note that first output has "0x0" as value of 'p', and the second has
> > "(void *)0x0".
>
> Also, the first one shows the func= part, the second doesn't.  

Heh, the second is not supposed to show func= part at all. MI does not have a 
command equivalent to "backtrace". One has to list -stack-list-frames (that 
does include func=) and -stack-list-arguments (that includes only argument). 
BTW, not very convenient.

> Looks 
> like a bug to me: those two should both use the same code.

Should I file a bug?

- Volodya

Re: MI: type prefixes for values

[Eli Zaretskii]

> From: Vladimir Prus <ghost@cs.msu.su>
> Date: Fri, 17 Feb 2006 13:29:33 +0300
> Cc: gdb@sources.redhat.com
> 
> > Are you saying that you don't want to show your users the fact that
> > the pointed object is a function?
> 
> At the very least, not in the way that gdb assumes.

In what way, then?

> > > I imagine it's a simple matter of wrapping some code in
> > > "ui_output_is_mi_like_p". Can somebody comment on this proposal?
> >
> > I think this will lose useful information.  So for now I object.
> 
> You can get the type information via the -var-info-type, which is more formal 
> way to get this information.

Why is it more formal, and why should we force the front end to send
yet another command to get this information?  Increasing
communications between the front end and GDB is not a good idea, I
think.

> > >     (gdb)
> > >     -thread-select 2
> > >     ^done,new-thread-id="2",frame={level="0",func="thread",
> > >     args=[{name="p",value="0x0"}],..........
> > >    (gdb)
> > >    -stack-list-arguments 1 0 0
> > >    ^done,stack-args=[frame={level="0",
> > >    args=[{name="p",value="(void *) 0x0"}]}]
> > >
> > > Note that first output has "0x0" as value of 'p', and the second has
> > > "(void *)0x0".
> >
> > Also, the first one shows the func= part, the second doesn't.  
> 
> Heh, the second is not supposed to show func= part at all. MI does not have a 
> command equivalent to "backtrace". One has to list -stack-list-frames (that 
> does include func=) and -stack-list-arguments (that includes only argument). 
> BTW, not very convenient.

Perhaps MI should have an equivalent of backtrace.

> > Looks 
> > like a bug to me: those two should both use the same code.
> 
> Should I file a bug?

Yes, I think so.

Re: MI: type prefixes for values

[Nick Roberts]

 > > > Also, I note that gdb is currently inconsitent even within itself:
 > > >
 > > >     (gdb)
 > > >     -thread-select 2
 > > >     ^done,new-thread-id="2",frame={level="0",func="thread",
 > > >     args=[{name="p",value="0x0"}],..........
 > > >    (gdb)
 > > >    -stack-list-arguments 1 0 0
 > > >    ^done,stack-args=[frame={level="0",
 > > >    args=[{name="p",value="(void *) 0x0"}]}]
 > > >
 > > > Note that first output has "0x0" as value of 'p', and the second has
 > > > "(void *)0x0".
 > >
 > > Also, the first one shows the func= part, the second doesn't.  
 > 
 > Heh, the second is not supposed to show func= part at all. MI does not have a 
 > command equivalent to "backtrace". One has to list -stack-list-frames (that 
 > does include func=) and -stack-list-arguments (that includes only argument). 
 > BTW, not very convenient.
 > 
 > > Looks 
 > > like a bug to me: those two should both use the same code.
 > 
 > Should I file a bug?

Looking at the code -thread-select uses common_val_print which calls
val_print, while -stack-list-arguments uses print_variable_value which calls
value_print. -stack-list-arguments shares code with -stack-list-locals which
can print type information anyway, so if a common style is agreed, I would
prefer the former.  Perhaps the call to print_variable_value in
list_args_or_locals can just be replaced to a call to common_val_print.

But there are probably many more inconsistencies and missing or redundant
fields.  It won't be possible to add all these in a piecemeal fashion without
repeatedly breaking an existing frontend. I think that a branch is needed so
that the collective changes can be merged into mainline in one go.  I have
already stated that I want to create a branch for the asynchronous stuff.
Perhaps the changes could go there (I'm still waiting for Emacs 22 to be
released to avoid to much dilution of effort).


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

Re: MI: type prefixes for values

[Eli Zaretskii]

> From: Vladimir Prus <ghost@cs.msu.su>
> Date: Fri, 17 Feb 2006 14:50:16 +0300
> 
> On Friday 17 February 2006 14:26, Eli Zaretskii wrote:
> > > From: Vladimir Prus <ghost@cs.msu.su>
> > > Date: Fri, 17 Feb 2006 13:29:33 +0300
> > > Cc: gdb@sources.redhat.com
> > >
> > > > Are you saying that you don't want to show your users the fact that
> > > > the pointed object is a function?
> > >
> > > At the very least, not in the way that gdb assumes.
> >
> > In what way, then?
> 
> 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.

The important thing is, you do use this information.

> In the output of print, the type of variable is sometimes wrapped in
> {}, sometimes in (), and there are no formal rules a frontend author
> can use to extract type from this information.

The formal rules can be stated, if that's what is missing.  The code
that produces the parentheses is deterministic, so the rules for when
they are used can be defined.

> > and why should we force the front end to send 
> > yet another command to get this information?  
> 
> Because it has to do this anyway -- the type is embedded in value only for 
> some special types, and frontend needs type information anyway.

Then perhaps we should add the type info to all arguments, instead of
removing it from where it exists now.

Re: MI: type prefixes for values

[Daniel Jacobowitz]

On Fri, Feb 17, 2006 at 03:49:33PM +0200, Eli Zaretskii wrote:
> 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.

The interesting thing to learn from this conversation, IMO, is that a
frontend is likely to show the type separately from the value.  So
maybe we should provide value= and type= if we want to provide both.

The GDB CLI chooses to show types for some kinds of variables, and not
for others.  That's its perogative, but exposing that CLI decision over
MI seems like a bad idea.

There's plenty of other things like this.  For instance, IIRC, the MI
value output will include the <repeats 16 times> annotations used by
the CLI in some cases.

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI: type prefixes for values

[Vladimir Prus]

On Friday 17 February 2006 16:49, Eli Zaretskii wrote:
> > From: Vladimir Prus <ghost@cs.msu.su>
> > Date: Fri, 17 Feb 2006 14:50:16 +0300
> >
> > On Friday 17 February 2006 14:26, Eli Zaretskii wrote:
> > > > From: Vladimir Prus <ghost@cs.msu.su>
> > > > Date: Fri, 17 Feb 2006 13:29:33 +0300
> > > > Cc: gdb@sources.redhat.com
> > > >
> > > > > Are you saying that you don't want to show your users the fact that
> > > > > the pointed object is a function?
> > > >
> > > > At the very least, not in the way that gdb assumes.
> > >
> > > In what way, then?
> >
> > 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.

> The important thing is, you do use this information.
>
> > In the output of print, the type of variable is sometimes wrapped in
> > {}, sometimes in (), and there are no formal rules a frontend author
> > can use to extract type from this information.
>
> The formal rules can be stated, if that's what is missing.  The code
> that produces the parentheses is deterministic, so the rules for when
> they are used can be defined.

Sure, they can be stated. But:
- I don't think anobody is working on that
- The parsing of that value will have to be done by ad-hoc code, which is 
contrary to MI-goal of being easily parsable.

> > > and why should we force the front end to send
> > > yet another command to get this information?
> >
> > Because it has to do this anyway -- the type is embedded in value only
> > for some special types, and frontend needs type information anyway.
>
> 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 *"

In that case, we don't need to document how type is added to value, and 
frontend author don't need to extract the type in ad-hoc way, he's just use 
regular way to access MI field value.

- Volodya

Re: MI: type prefixes for values

[Eli Zaretskii]

> Date: Fri, 17 Feb 2006 08:54:51 -0500
> From: Daniel Jacobowitz <drow@false.org>
> 
> The interesting thing to learn from this conversation, IMO, is that a
> frontend is likely to show the type separately from the value.  So
> maybe we should provide value= and type= if we want to provide both.

I'm okay with the two fields approach.

Re: MI: type prefixes for values

[Eli Zaretskii]

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

> > > In the output of print, the type of variable is sometimes wrapped in
> > > {}, sometimes in (), and there are no formal rules a frontend author
> > > can use to extract type from this information.
> >
> > The formal rules can be stated, if that's what is missing.  The code
> > that produces the parentheses is deterministic, so the rules for when
> > they are used can be defined.
> 
> Sure, they can be stated. But:
> - I don't think anobody is working on that

Volunteers are welcome.

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

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

Re: MI: type prefixes for values

[Vladimir Prus]

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

Re: MI: type prefixes for values

[Bob Rossi]

> > > - 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);
>         }

Hi Volodya,

I have to say, this looks like a problem with the way you parse the
output of GDB. There should be no "stripping". If you parse it into a
data structure, you simply walk that structure and get the info you
want.

Bob Rossi

Re: MI: type prefixes for values

[Vladimir Prus]

On Friday 17 February 2006 17:26, Bob Rossi wrote:

> >   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);
> >         }
>

Hi Bob,

> I have to say, this looks like a problem with the way you parse the
> output of GDB. There should be no "stripping". If you parse it into a
> data structure, you simply walk that structure and get the info you
> want.

I'm afraid I don't get you. If I'm given literal string 
"{int (*)(int)} 0x12345678" by gdb, and I want to display it without "{}", 
then I surely have to remove the "{}" part, no?

Or you wanted to say I should use variable objects and traverse the tree 
structure they have? If so, can you expand on this?

Thanks,
Volodya

Re: MI: type prefixes for values

[Bob Rossi]

On Fri, Feb 17, 2006 at 05:35:13PM +0300, Vladimir Prus wrote:
> On Friday 17 February 2006 17:26, Bob Rossi wrote:
> 
> > >   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);
> > >         }
> >
> 
> Hi Bob,
> 
> > I have to say, this looks like a problem with the way you parse the
> > output of GDB. There should be no "stripping". If you parse it into a
> > data structure, you simply walk that structure and get the info you
> > want.
> 
> I'm afraid I don't get you. If I'm given literal string 
> "{int (*)(int)} 0x12345678" by gdb, and I want to display it without "{}", 
> then I surely have to remove the "{}" part, no?

OK, I misunderstood what you were doing there. Sorry. I have a personal
opinion that the FE is not capable of modifing data that GDB is passing
to it for display purposes. GDB is not bound to having {int (*)(int)},
and it could certainly change to [int (*)(int)] in the next release. (I
know it won't, but the point stands).

Any manipulation or parsing you do of the data that GDB passes back,
IMO, is on your hands. This is *as bad* as parsing the CLI output.

I would fully support the effort to have GDB give smaller chunks of
information, so that FE's can build on what it's given. 

Bob Rossi

Re: MI: type prefixes for values

[Vladimir Prus]

On Friday 17 February 2006 17:43, Bob Rossi wrote:

> > I'm afraid I don't get you. If I'm given literal string
> > "{int (*)(int)} 0x12345678" by gdb, and I want to display it without
> > "{}", then I surely have to remove the "{}" part, no?
>
> OK, I misunderstood what you were doing there. Sorry. I have a personal
> opinion that the FE is not capable of modifing data that GDB is passing
> to it for display purposes. GDB is not bound to having {int (*)(int)},
> and it could certainly change to [int (*)(int)] in the next release. (I
> know it won't, but the point stands).
>
> Any manipulation or parsing you do of the data that GDB passes back,
> IMO, is on your hands. This is *as bad* as parsing the CLI output.

Exactly. The reason I'm raising this issue is not to have to parse this data 
in future.

> I would fully support the effort to have GDB give smaller chunks of
> information, so that FE's can build on what it's given.

Great. Seems like Daniel and Eli are of the same mind? I'll try to implement 
this, then.

- Volodya

Re: MI: type prefixes for values

[Eli Zaretskii]

> From: Vladimir Prus <ghost@cs.msu.su>
> Date: Fri, 17 Feb 2006 17:24:03 +0300
> Cc: gdb@sources.redhat.com
> 
> > > - 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);
>         }

I'd never suspect that someone would try to parse MI with such
ad-hoc'ish code.  I assumed that a decent parser was being used, and
that this parser could simply choose the right template--either the
one for response with braces, or the one for without.

With such one-character-at-a-time parsing of MI's output, I now
understand why you want MI to talk in small chunks.  This code is okay
for parsing irregular streams such as what CLI produces, but that's not
the right way of dealing with structured data streams such as the one
produced by MI.  You need a fairly general-purpose reader that would
create a data structure for what it reads and populate the structure's
members with what it finds in MI's output.  Then you just pluck
whatever you need from that data structure.

I really don't think that we should cater to such ``parsers''.  They
need to be thrown away and rewritten, IMO.

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

The same way a compiler's parser decides: by writing code that checks
the text against several templates and finding the one that matches.
I believe people who defined and implemented MI intended for its
output to be structured so that it could be easily parsed, but you
need to write a parser that knows how to deal with structured text.
Take a look at an XML parser, for example, or at a Lisp reader.
That's how you should deal with this, IMO, not by looking at each
individual character in turn and trying to decide, based on that
single character, what could that mean.

> That code was written before me, and is 100 lines in size.

My advice is to throw it out and write a new one.  It is not suitable
for working with GDB/MI.

> > > > Then perhaps we should add the type info to all arguments, instead of
> > > > removing it from where it exists now.the writers
> > >
> > > 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?

I won't object.  But I still think you need to replace that parser.

Re: MI: type prefixes for values

[Daniel Jacobowitz]

On Fri, Feb 17, 2006 at 08:59:41PM +0200, Eli Zaretskii wrote:
> I'd never suspect that someone would try to parse MI with such
> ad-hoc'ish code.  I assumed that a decent parser was being used, and
> that this parser could simply choose the right template--either the
> one for response with braces, or the one for without.

To correct the record, he's not parsing MI here.  He's parsing the
value encapsulated within MI, the bit in quotes here:
    value="4000"
or:
    value="{int (int)} 0xffffffff <sym>"

There's no grammar describing what goes in the value string.

The value should pretty clearly be an opaque string to the front end.
He's made a good point that the opaque string shouldn't include the
function type.  I'm not sure about the <sym> bit...

For array contents he should be using variable objects, though.

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI: type prefixes for values

[Eli Zaretskii]

> Date: Fri, 17 Feb 2006 14:04:18 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Vladimir Prus <ghost@cs.msu.su>, gdb@sources.redhat.com
> 
> To correct the record, he's not parsing MI here.  He's parsing the
> value encapsulated within MI, the bit in quotes here:
>     value="4000"
> or:
>     value="{int (int)} 0xffffffff <sym>"

I understood that part.

> There's no grammar describing what goes in the value string.

How do you mean ``there's no grammar''?  Do you mean it cannot be
written?  Or do you mean it was not written yet?  If the latter, then
if I needed to write a code to parse this, I'd write down a formal
definition of what I'll expect, before writing code to parse that.

Re: MI: type prefixes for values

[Daniel Jacobowitz]

On Fri, Feb 17, 2006 at 09:25:42PM +0200, Eli Zaretskii wrote:
> > Date: Fri, 17 Feb 2006 14:04:18 -0500
> > From: Daniel Jacobowitz <drow@false.org>
> > Cc: Vladimir Prus <ghost@cs.msu.su>, gdb@sources.redhat.com
> > 
> > To correct the record, he's not parsing MI here.  He's parsing the
> > value encapsulated within MI, the bit in quotes here:
> >     value="4000"
> > or:
> >     value="{int (int)} 0xffffffff <sym>"
> 
> I understood that part.
> 
> > There's no grammar describing what goes in the value string.
> 
> How do you mean ``there's no grammar''?  Do you mean it cannot be
> written?  Or do you mean it was not written yet?  If the latter, then
> if I needed to write a code to parse this, I'd write down a formal
> definition of what I'll expect, before writing code to parse that.

I mean that there's no documented grammar, which in turn means (among
other things) that GDB doesn't guarantee its contents as part of a
stable interface.  Parsing it is a bad idea; either it's opaque, or it
isn't.

Writing a grammar for it would be difficult-to-impractical.  For
functions, it could be any C function type; for arrays, it could be
a list of anything GDB considers a value.

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI: type prefixes for values

[Bob Rossi]

On Fri, Feb 17, 2006 at 09:25:42PM +0200, Eli Zaretskii wrote:
> > Date: Fri, 17 Feb 2006 14:04:18 -0500
> > From: Daniel Jacobowitz <drow@false.org>
> > Cc: Vladimir Prus <ghost@cs.msu.su>, gdb@sources.redhat.com
> > 
> > To correct the record, he's not parsing MI here.  He's parsing the
> > value encapsulated within MI, the bit in quotes here:
> >     value="4000"
> > or:
> >     value="{int (int)} 0xffffffff <sym>"
> 
> I understood that part.
> 
> > There's no grammar describing what goes in the value string.
> 
> How do you mean ``there's no grammar''?  Do you mean it cannot be
> written?  Or do you mean it was not written yet?  If the latter, then
> if I needed to write a code to parse this, I'd write down a formal
> definition of what I'll expect, before writing code to parse that.

Eli, I'm suggesting that there is not, and can never be a reliable
formal description for parsing the data in the field 'value'.

GDB is free to change that string to whatever it wants in the future.
That string is not supposed to be parsed. So don't do it. If GDB wants
that data to be parsable, it would need to describe a language that
could parse it, and FE's could implement it. But what would be the 
point?

Vladimir, stop trying to parse fields that are unparsable by nature. If
you want to parse the data, your on your own. If you submit a patch that
makes GDB output data in more atomic pieces, I think everyone would be
OK with that.

Bob Rossi

Re: MI: type prefixes for values

[Eli Zaretskii]

> Date: Fri, 17 Feb 2006 14:35:56 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Vladimir Prus <ghost@cs.msu.su>, gdb@sources.redhat.com
> 
> Writing a grammar for it would be difficult-to-impractical.

It doesn't need to be a formal grammar, just a spec that is accurate
enough to build a reader.

MI should have a regular syntax which allows such a spec.  If MI
doesn't support that, then it misses its main design goal.

Re: MI: type prefixes for values

[Eli Zaretskii]

> Date: Fri, 17 Feb 2006 14:35:58 -0500
> From: Bob Rossi <bob@brasko.net>
> Cc: Vladimir Prus <ghost@cs.msu.su>, gdb@sources.redhat.com
> 
> Eli, I'm suggesting that there is not, and can never be a reliable
> formal description for parsing the data in the field 'value'.

I cannot disagree more.  MI _must_ allow such a description, or else
it fails to meet its design goals.

Re: MI: type prefixes for values

[Bob Rossi]

On Fri, Feb 17, 2006 at 09:52:46PM +0200, Eli Zaretskii wrote:
> > Date: Fri, 17 Feb 2006 14:35:56 -0500
> > From: Daniel Jacobowitz <drow@false.org>
> > Cc: Vladimir Prus <ghost@cs.msu.su>, gdb@sources.redhat.com
> > 
> > Writing a grammar for it would be difficult-to-impractical.
> 
> It doesn't need to be a formal grammar, just a spec that is accurate
> enough to build a reader.
> 
> MI should have a regular syntax which allows such a spec.  If MI
> doesn't support that, then it misses its main design goal.

I completly disagree. MI has a design spec that allows a FE to parse the
output of GDB. The data that it get's back from GDB is a whole different
story. I expect that data to be useable at best by the front end.

Bob Rossi

Re: MI: type prefixes for values

[Eli Zaretskii]

> Date: Fri, 17 Feb 2006 14:59:09 -0500
> From: Bob Rossi <bob@brasko.net>
> Cc: Vladimir Prus <ghost@cs.msu.su>, gdb@sources.redhat.com
> 
> > MI should have a regular syntax which allows such a spec.  If MI
> > doesn't support that, then it misses its main design goal.
> 
> I completly disagree. MI has a design spec that allows a FE to parse the
> output of GDB. The data that it get's back from GDB is a whole different
> story.

Data is just one part of the output of GDB, so it should be parsable
like the rest, IMO.

Re: MI: type prefixes for values

[Daniel Jacobowitz]

On Fri, Feb 17, 2006 at 10:04:13PM +0200, Eli Zaretskii wrote:
> > Date: Fri, 17 Feb 2006 14:59:09 -0500
> > From: Bob Rossi <bob@brasko.net>
> > Cc: Vladimir Prus <ghost@cs.msu.su>, gdb@sources.redhat.com
> > 
> > > MI should have a regular syntax which allows such a spec.  If MI
> > > doesn't support that, then it misses its main design goal.
> > 
> > I completly disagree. MI has a design spec that allows a FE to parse the
> > output of GDB. The data that it get's back from GDB is a whole different
> > story.
> 
> Data is just one part of the output of GDB, so it should be parsable
> like the rest, IMO.

And how would you suggest to accomplish this daunting task?

The data is language-specific and program-specific.  It's been up and
down GDB's value machinery and formatted in the most user-intelligible
way that we can manage.  If the front end needs to know more about it,
then it should use the MI variable-object interface to see its internal
structure and bits; that's how you're supposed to peek inside of
values.

The real problem here is that Vladimir is trying to parse the result of
-data-evaluate-expression, which is defined as opaque.  Maybe someone
should design a major interface change where values are returned as
varobjs instead of strings.

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI: type prefixes for values

[Bob Rossi]

On Fri, Feb 17, 2006 at 10:04:13PM +0200, Eli Zaretskii wrote:
> > Date: Fri, 17 Feb 2006 14:59:09 -0500
> > From: Bob Rossi <bob@brasko.net>
> > Cc: Vladimir Prus <ghost@cs.msu.su>, gdb@sources.redhat.com
> > 
> > > MI should have a regular syntax which allows such a spec.  If MI
> > > doesn't support that, then it misses its main design goal.
> > 
> > I completly disagree. MI has a design spec that allows a FE to parse the
> > output of GDB. The data that it get's back from GDB is a whole different
> > story.
> 
> Data is just one part of the output of GDB, so it should be parsable
> like the rest, IMO.

I respect your opinion here. I think it's slightly impractical, but also
it's already assummed correct. I really think it's OK to say, this field
is a number, or this field is a string. If it's a string, no one expects
to parse it. I mean, GDB probably doesn't even know how to parse it.
Especially when displaying type information, or some other complex
data.

For instance, if it's a filename, I think it should be a string.
However, I'm not going to document a grammar that parses a filename on
any given system. If it outputs a type, I'm not going to document how to
parse a type in a given language. For one, it's to complicated for me to
even do.

With that said, I think it would be necesary to allow the FE to know if
a particular field is supposed to be a number or string (etc). However,
parsing the contents of those strings is just not practical.

Bob Rossi

Re: MI: type prefixes for values

[Eli Zaretskii]

> Date: Fri, 17 Feb 2006 15:15:37 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Vladimir Prus <ghost@cs.msu.su>, gdb@sources.redhat.com
> 
> The real problem here is that Vladimir is trying to parse the result of
> -data-evaluate-expression, which is defined as opaque.  Maybe someone
> should design a major interface change where values are returned as
> varobjs instead of strings.

Maybe, I don't know.  If the results of -data-evaluate-expression are
designed to be unparsable, then indeed Vladimir shouldn't try that;
but then there should be some way of getting that information in an
easily parsable way.

Re: MI: type prefixes for values

[Daniel Jacobowitz]

On Fri, Feb 17, 2006 at 10:22:32PM +0200, Eli Zaretskii wrote:
> > Date: Fri, 17 Feb 2006 15:15:37 -0500
> > From: Daniel Jacobowitz <drow@false.org>
> > Cc: Vladimir Prus <ghost@cs.msu.su>, gdb@sources.redhat.com
> > 
> > The real problem here is that Vladimir is trying to parse the result of
> > -data-evaluate-expression, which is defined as opaque.  Maybe someone
> > should design a major interface change where values are returned as
> > varobjs instead of strings.
> 
> Maybe, I don't know.  If the results of -data-evaluate-expression are
> designed to be unparsable, then indeed Vladimir shouldn't try that;
> but then there should be some way of getting that information in an
> easily parsable way.

What a great idea!  Conveniently someone else already thought of it :-)

-var-create - * "getpid()"
^done,name="var1",numchild="0",type="int"
(gdb) 
-var-evaluate-expression var1
^done,value="31989"

(then -var-delete when you're done)

Now, this appears at first no different.  It has an opaque value
string.  And for functions it has the annoying {int (int)}.  But
I think we've agreed that we can remove that, and for compound
values you can decompose it using -var-list-children, and you can query
its formatted type separately:

-var-info-type var1
^done,type="int"

For the record, it evaluates the call at -var-create time rather than
-var-evaluate-expression, as I would hope.  The result is somewhat
strange if GDB hits a breakpoint while doing so.

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI: type prefixes for values

[Daniel Jacobowitz]

On Fri, Feb 17, 2006 at 03:18:37PM -0500, Bob Rossi wrote:
> With that said, I think it would be necesary to allow the FE to know if
> a particular field is supposed to be a number or string (etc). However,
> parsing the contents of those strings is just not practical.

If fields have a static "type" in this sense, maybe we can add it to
the specification.

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI: type prefixes for values

[Jim Ingham]

And... since the varobj's only parse the expression once when the  
varobj is created, getting the current values of varobj's is much  
faster than doing -data-evaluate-expression.  Not a big deal if you  
are just printing one value.  But if you are trying to update all the  
local variables on every step, this can be significant.  People tend  
to be pretty sensitive to the speed of the "step" operation...

If you're writing a front end using the MI, you are better off using  
variable objects for anything that you are likely to refresh more  
than one or two times.

In Xcode, we do use -data-evaluate-expression, but only when we are  
doing function calls where we know the call we are making and what to  
expect back.  In this case the overhead of the variable object is not  
worth the trouble.  Other than that, we use varobj's...

Jim

On Feb 17, 2006, at 12:31 PM, Daniel Jacobowitz wrote:

> On Fri, Feb 17, 2006 at 10:22:32PM +0200, Eli Zaretskii wrote:
>>> Date: Fri, 17 Feb 2006 15:15:37 -0500
>>> From: Daniel Jacobowitz <drow@false.org>
>>> Cc: Vladimir Prus <ghost@cs.msu.su>, gdb@sources.redhat.com
>>>
>>> The real problem here is that Vladimir is trying to parse the  
>>> result of
>>> -data-evaluate-expression, which is defined as opaque.  Maybe  
>>> someone
>>> should design a major interface change where values are returned as
>>> varobjs instead of strings.
>>
>> Maybe, I don't know.  If the results of -data-evaluate-expression are
>> designed to be unparsable, then indeed Vladimir shouldn't try that;
>> but then there should be some way of getting that information in an
>> easily parsable way.
>
> What a great idea!  Conveniently someone else already thought of  
> it :-)
>
> -var-create - * "getpid()"
> ^done,name="var1",numchild="0",type="int"
> (gdb)
> -var-evaluate-expression var1
> ^done,value="31989"
>
> (then -var-delete when you're done)
>
> Now, this appears at first no different.  It has an opaque value
> string.  And for functions it has the annoying {int (int)}.  But
> I think we've agreed that we can remove that, and for compound
> values you can decompose it using -var-list-children, and you can  
> query
> its formatted type separately:
>
> -var-info-type var1
> ^done,type="int"
>
> For the record, it evaluates the call at -var-create time rather than
> -var-evaluate-expression, as I would hope.  The result is somewhat
> strange if GDB hits a breakpoint while doing so.
>
> -- 
> Daniel Jacobowitz
> CodeSourcery

Re: MI: type prefixes for values

[Daniel Jacobowitz]

On Fri, Feb 17, 2006 at 03:31:20PM -0500, Daniel Jacobowitz wrote:
> On Fri, Feb 17, 2006 at 10:22:32PM +0200, Eli Zaretskii wrote:
> > > Date: Fri, 17 Feb 2006 15:15:37 -0500
> > > From: Daniel Jacobowitz <drow@false.org>
> > > Cc: Vladimir Prus <ghost@cs.msu.su>, gdb@sources.redhat.com
> > > 
> > > The real problem here is that Vladimir is trying to parse the result of
> > > -data-evaluate-expression, which is defined as opaque.  Maybe someone
> > > should design a major interface change where values are returned as
> > > varobjs instead of strings.
> > 
> > Maybe, I don't know.  If the results of -data-evaluate-expression are
> > designed to be unparsable, then indeed Vladimir shouldn't try that;
> > but then there should be some way of getting that information in an
> > easily parsable way.
> 
> What a great idea!  Conveniently someone else already thought of it :-)

Oh, just in case it wasn't clear: this obsoletes may suggestion above;
I had not realized you could do this with the existing -var-create
until I went to look.

Maybe a note about this under -data-evaluate-expression is in order.

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI: type prefixes for values

[Eli Zaretskii]

> Cc: Eli Zaretskii <eliz@gnu.org>, Vladimir Prus <ghost@cs.msu.su>,
>         gdb@sources.redhat.com
> From: Jim Ingham <jingham@apple.com>
> Date: Fri, 17 Feb 2006 12:40:52 -0800
> 
> And... since the varobj's only parse the expression once when the  
> varobj is created, getting the current values of varobj's is much  
> faster than doing -data-evaluate-expression.  Not a big deal if you  
> are just printing one value.  But if you are trying to update all the  
> local variables on every step, this can be significant.  People tend  
> to be pretty sensitive to the speed of the "step" operation...
> 
> If you're writing a front end using the MI, you are better off using  
> variable objects for anything that you are likely to refresh more  
> than one or two times.
> 
> In Xcode, we do use -data-evaluate-expression, but only when we are  
> doing function calls where we know the call we are making and what to  
> expect back.  In this case the overhead of the variable object is not  
> worth the trouble.  Other than that, we use varobj's...

Jim, how about if you (and everyone else who has working knowledge of
using MI in front ends) write a section for the GDB manual with
various do's and dont's, such as those you mention above?  I think
this would be a useful addition to the manual, one that could
significantly boost developers' readiness to switch to MI and use it
wisely.  Right now, every one of them needs to discover this on their
own.

Re: MI: type prefixes for values

[Vladimir Prus]

On Friday 17 February 2006 22:35, Bob Rossi wrote:

> Vladimir, stop trying to parse fields that are unparsable by nature. If
> you want to parse the data, your on your own. If you submit a patch that
> makes GDB output data in more atomic pieces, I think everyone would be
> OK with that.

We're running in circles. I've asked about possible patch, but instead got 
lengthy replies about how parsing value field is bad idea. To repeat -- I 
started this thread because *I* want to avoid parsing that field.

To make an even more specific question, I propose to:

   - Remove type prefix from output of -data-evaluate-expression and
        -var-evaluat-expression
   
   - Add 'type' field to the output of -data-evaluate-expression


Is this OK with everyone?

- Volodya

Re: MI: type prefixes for values

[Vladimir Prus]

On Friday 17 February 2006 23:40, Jim Ingham wrote:
> And... since the varobj's only parse the expression once when the
> varobj is created, getting the current values of varobj's is much
> faster than doing -data-evaluate-expression.  Not a big deal if you
> are just printing one value.  But if you are trying to update all the
> local variables on every step, this can be significant.  People tend
> to be pretty sensitive to the speed of the "step" operation...

Hi Jim,

can you provide some concrete numbers? Specifically, is using varobj to get 
values of all local variables faster then a single -stack-list-locals, and if 
so, by how much?

Thanks,
Volodya

Re: MI: type prefixes for values

[Vladimir Prus]

On Saturday 18 February 2006 13:56, Eli Zaretskii wrote:

> > In Xcode, we do use -data-evaluate-expression, but only when we are
> > doing function calls where we know the call we are making and what to
> > expect back.  In this case the overhead of the variable object is not
> > worth the trouble.  Other than that, we use varobj's...
>
> Jim, how about if you (and everyone else who has working knowledge of
> using MI in front ends) write a section for the GDB manual with
> various do's and dont's, such as those you mention above?  I think
> this would be a useful addition to the manual, one that could
> significantly boost developers' readiness to switch to MI and use it
> wisely.  Right now, every one of them needs to discover this on their
> own.

Seconded. Specifically, the introduction to variables object section is 
hopelessy unclear at the moment. If somebody could put up a short explanation 
why they are good, and what's the best way to use them, this will be great.

- Volodya 

Re: MI: type prefixes for values

[Vladimir Prus]

On Friday 17 February 2006 21:59, Eli Zaretskii wrote:
> > From: Vladimir Prus <ghost@cs.msu.su>
> > Date: Fri, 17 Feb 2006 17:24:03 +0300
> > Cc: gdb@sources.redhat.com
> >
> > > > - 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);
> >         }
>
> I'd never suspect that someone would try to parse MI with such
> ad-hoc'ish code.  I assumed that a decent parser was being used, and
> that this parser could simply choose the right template--either the
> one for response with braces, or the one for without.
>
> With such one-character-at-a-time parsing of MI's output, I now
> understand why you want MI to talk in small chunks.  This code is okay
> for parsing irregular streams such as what CLI produces, but that's not
> the right way of dealing with structured data streams such as the one
> produced by MI.  You need a fairly general-purpose reader that would
> create a data structure for what it reads and populate the structure's
> members with what it finds in MI's output.  Then you just pluck
> whatever you need from that data structure.
>
> I really don't think that we should cater to such ``parsers''.  They
> need to be thrown away and rewritten, IMO.

Eli,
I'm disappointed by you making such broad statements based on no data. 
Had you looked at code:

   http://websvn.kde.org/branches/work/kdevelop-debugger-mi/mi/
   http://websvn.kde.org/branches/work/kdevelop-debugger-mi/mi/gdbmi.h?rev=504799&view=markup

you'd notice that a data structure is being created. And as I've already said in this thread:

   http://article.gmane.org/gmane.comp.gdb.devel/15652

the "breace-removing" code is specifically for removing uncessary data from "value" literals, which 
have no formal grammar.


> > 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?
>
> The same way a compiler's parser decides: by writing code that checks
> the text against several templates and finding the one that matches.
> I believe people who defined and implemented MI intended for its
> output to be structured so that it could be easily parsed, but you
> need to write a parser that knows how to deal with structured text.
> Take a look at an XML parser, for example, or at a Lisp reader.

Can you please avoid giving generic advice about writing parsers?

> That's how you should deal with this, IMO, not by looking at each
> individual character in turn and trying to decide, based on that
> single character, what could that mean.

I belive you're missing something. The *formal grammar* 
of MI is actually LL(1), so it can be parsed exactly by looking 
at one next character and deciding what to do. 

> > > > > Then perhaps we should add the type info to all arguments, instead
> > > > > of removing it from where it exists now.the writers
> > > >
> > > > 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?
>
> I won't object.  But I still think you need to replace that parser.

I think not.

- Volodya

Re: MI: type prefixes for values

[Jim Ingham]

Making variable objects is always slower than just printing the  
values if you are only doing it one time.  The variable objects don't  
do any magic to get their values - they go through the same code as  
"print" does ultimately, but they do a little more work getting  
there.  The overhead is not all that great, however.  Just malloc'ing  
some data structures and inserting them into a list somewhere.

The advantage of variable objects is that they cache the parsed  
expression.  So the second & third etc. evaluation is much faster.   
This is a pretty common usage pattern, especially with local  
variables, since you usually step a number of times in any given  
frame, and the locals all have to be updated with each step.  The  
variable objects have some other convenient features, like the -var- 
update command which refreshes the values will report only the  
variable objects whose values have changed, so the front end has to  
fetch less data.

It's been such a long time (~5 years) since we switched over to  
variable objects in ProjectBuilder (now Xcode) that I don't have any  
concrete numbers any more, sorry.

BTW, one of the things we added on our side was an option to -stack- 
list-locals to make variable objects for all the locals it returns.   
This is very convenient.

We also added the option to return all the locals in all the blocks  
in a function.  This allows you to present all the variables, and  
then mark the ones which are not currently in scope appropriately.  I  
find this less confusing than having the contents of the variables  
window come and go as you step through the function.  Most of our  
users seem to agree.

Jim

On Feb 19, 2006, at 11:26 PM, Vladimir Prus wrote:

> On Friday 17 February 2006 23:40, Jim Ingham wrote:
>> And... since the varobj's only parse the expression once when the
>> varobj is created, getting the current values of varobj's is much
>> faster than doing -data-evaluate-expression.  Not a big deal if you
>> are just printing one value.  But if you are trying to update all the
>> local variables on every step, this can be significant.  People tend
>> to be pretty sensitive to the speed of the "step" operation...
>
> Hi Jim,
>
> can you provide some concrete numbers? Specifically, is using  
> varobj to get
> values of all local variables faster then a single -stack-list- 
> locals, and if
> so, by how much?
>
> Thanks,
> Volodya

Re: MI: type prefixes for values

[Daniel Jacobowitz]

On Mon, Feb 20, 2006 at 10:58:07AM -0800, Jim Ingham wrote:
> We also added the option to return all the locals in all the blocks  
> in a function.  This allows you to present all the variables, and  
> then mark the ones which are not currently in scope appropriately.  I  
> find this less confusing than having the contents of the variables  
> window come and go as you step through the function.  Most of our  
> users seem to agree.

Ooh... that does sound like a nice one, assuming it handles the nasty
cases like shadowing somehow.

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI: type prefixes for values

[Jim Ingham]

On Feb 20, 2006, at 11:12 AM, Daniel Jacobowitz wrote:

> On Mon, Feb 20, 2006 at 10:58:07AM -0800, Jim Ingham wrote:
>> We also added the option to return all the locals in all the blocks
>> in a function.  This allows you to present all the variables, and
>> then mark the ones which are not currently in scope appropriately.  I
>> find this less confusing than having the contents of the variables
>> window come and go as you step through the function.  Most of our
>> users seem to agree.
>
> Ooh... that does sound like a nice one, assuming it handles the nasty
> cases like shadowing somehow.

Yes, it took a little work to get this right, but it does so far as I  
have been able to determine (i.e. don't have any outstanding bugs on  
this one.)

Jim

>
> -- 
> Daniel Jacobowitz
> CodeSourcery

Re: MI: type prefixes for values

[Eli Zaretskii]

> From: Vladimir Prus <ghost@cs.msu.su>
> Date: Mon, 20 Feb 2006 10:23:04 +0300
> Cc: Eli Zaretskii <eliz@gnu.org>,
>  gdb@sources.redhat.com
> 
> To make an even more specific question, I propose to:
> 
>    - Remove type prefix from output of -data-evaluate-expression and
>         -var-evaluat-expression
>    
>    - Add 'type' field to the output of -data-evaluate-expression
> 
> 
> Is this OK with everyone?

I think a better suggestion surfaced in this discussion: don't try to
parse the output of -data-evaluate-expression, and use -var-create
instead.  Is that good enough?  If not, why not?

Re: MI: type prefixes for values

[Daniel Jacobowitz]

On Mon, Feb 20, 2006 at 10:55:44PM +0200, Eli Zaretskii wrote:
> > From: Vladimir Prus <ghost@cs.msu.su>
> > Date: Mon, 20 Feb 2006 10:23:04 +0300
> > Cc: Eli Zaretskii <eliz@gnu.org>,
> >  gdb@sources.redhat.com
> > 
> > To make an even more specific question, I propose to:
> > 
> >    - Remove type prefix from output of -data-evaluate-expression and
> >         -var-evaluat-expression
> >    
> >    - Add 'type' field to the output of -data-evaluate-expression
> > 
> > 
> > Is this OK with everyone?
> 
> I think a better suggestion surfaced in this discussion: don't try to
> parse the output of -data-evaluate-expression, and use -var-create
> instead.  Is that good enough?  If not, why not?

Yes; I think (and Jim's experience seems to confirm) that
-var-evaluate-expression is sufficiently cheap that if you need
more than a simple string output, you should use it.

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI: type prefixes for values

[Vladimir Prus]

On Monday 20 February 2006 21:58, Jim Ingham wrote:
> Making variable objects is always slower than just printing the
> values if you are only doing it one time.  The variable objects don't
> do any magic to get their values - they go through the same code as
> "print" does ultimately, but they do a little more work getting
> there.  The overhead is not all that great, however.  Just malloc'ing
> some data structures and inserting them into a list somewhere.
>
> The advantage of variable objects is that they cache the parsed
> expression.  So the second & third etc. evaluation is much faster.
> This is a pretty common usage pattern, especially with local
> variables, since you usually step a number of times in any given
> frame, and the locals all have to be updated with each step.  The
> variable objects have some other convenient features, like the -var-
> update command which refreshes the values will report only the
> variable objects whose values have changed, so the front end has to
> fetch less data.

Say, I've created a bunch of variable objects for for local variables. When I 
leave the function, those variables become invalid. How do you detect this 
case? Do you have a command '-list-var-objects-that-are-dead', or some other 
mechanism.

> We also added the option to return all the locals in all the blocks
> in a function.  This allows you to present all the variables, and
> then mark the ones which are not currently in scope appropriately.  I
> find this less confusing than having the contents of the variables
> window come and go as you step through the function.  Most of our
> users seem to agree.

Heck, such a feature will immediately fix:

    http://bugs.kde.org/show_bug.cgi?id=120439

Is this patch available on some branch in the public CVS repository?

- Volodya

Re: MI: type prefixes for values

[Vladimir Prus]

On Monday 20 February 2006 23:57, Daniel Jacobowitz wrote:
> On Mon, Feb 20, 2006 at 10:55:44PM +0200, Eli Zaretskii wrote:
> > > From: Vladimir Prus <ghost@cs.msu.su>
> > > Date: Mon, 20 Feb 2006 10:23:04 +0300
> > > Cc: Eli Zaretskii <eliz@gnu.org>,
> > >  gdb@sources.redhat.com
> > >
> > > To make an even more specific question, I propose to:
> > >
> > >    - Remove type prefix from output of -data-evaluate-expression and
> > >         -var-evaluat-expression
> > >
> > >    - Add 'type' field to the output of -data-evaluate-expression
> > >
> > >
> > > Is this OK with everyone?
> >
> > I think a better suggestion surfaced in this discussion: don't try to
> > parse the output of -data-evaluate-expression, and use -var-create
> > instead.  Is that good enough?  If not, why not?
>
> Yes; I think (and Jim's experience seems to confirm) that
> -var-evaluate-expression is sufficiently cheap that if you need
> more than a simple string output, you should use it.

But output of -var-evaluate-expression includes that "type prefix" too! 

- Volodya

Re: MI: type prefixes for values

[Daniel Jacobowitz]

On Tue, Feb 21, 2006 at 09:54:43AM +0300, Vladimir Prus wrote:
> On Monday 20 February 2006 23:57, Daniel Jacobowitz wrote:
> > On Mon, Feb 20, 2006 at 10:55:44PM +0200, Eli Zaretskii wrote:
> > > > From: Vladimir Prus <ghost@cs.msu.su>
> > > > Date: Mon, 20 Feb 2006 10:23:04 +0300
> > > > Cc: Eli Zaretskii <eliz@gnu.org>,
> > > >  gdb@sources.redhat.com
> > > >
> > > > To make an even more specific question, I propose to:
> > > >
> > > >    - Remove type prefix from output of -data-evaluate-expression and
> > > >         -var-evaluat-expression
> > > >
> > > >    - Add 'type' field to the output of -data-evaluate-expression
> > > >
> > > >
> > > > Is this OK with everyone?
> > >
> > > I think a better suggestion surfaced in this discussion: don't try to
> > > parse the output of -data-evaluate-expression, and use -var-create
> > > instead.  Is that good enough?  If not, why not?
> >
> > Yes; I think (and Jim's experience seems to confirm) that
> > -var-evaluate-expression is sufficiently cheap that if you need
> > more than a simple string output, you should use it.
> 
> But output of -var-evaluate-expression includes that "type prefix" too! 

Yes, I believe we all agreed that it could be removed.

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI: type prefixes for values

[Jim Ingham]

On Feb 20, 2006, at 10:51 PM, Vladimir Prus wrote:

> On Monday 20 February 2006 21:58, Jim Ingham wrote:
>> Making variable objects is always slower than just printing the
>> values if you are only doing it one time.  The variable objects don't
>> do any magic to get their values - they go through the same code as
>> "print" does ultimately, but they do a little more work getting
>> there.  The overhead is not all that great, however.  Just malloc'ing
>> some data structures and inserting them into a list somewhere.
>>
>> The advantage of variable objects is that they cache the parsed
>> expression.  So the second & third etc. evaluation is much faster.
>> This is a pretty common usage pattern, especially with local
>> variables, since you usually step a number of times in any given
>> frame, and the locals all have to be updated with each step.  The
>> variable objects have some other convenient features, like the -var-
>> update command which refreshes the values will report only the
>> variable objects whose values have changed, so the front end has to
>> fetch less data.
>
> Say, I've created a bunch of variable objects for for local  
> variables. When I
> leave the function, those variables become invalid. How do you  
> detect this
> case? Do you have a command '-list-var-objects-that-are-dead', or  
> some other
> mechanism.

We don't do this in gdb.  Xcode keeps track of which varobj's go with  
which stack frames, and deletes them when appropriate.  You want to  
be a little clever about this, 'cause there's no need to delete the  
varobj's till the function is actually popped off the stack.  You  
might descend into another function then come back to this one, in  
which case the varobj's are still good.

Note, however, that the varobj's do remember their frames, so if you  
tried to evaluate one that was no longer on the stack, the varobj  
would report "out of scope".

>
>> We also added the option to return all the locals in all the blocks
>> in a function.  This allows you to present all the variables, and
>> then mark the ones which are not currently in scope appropriately.  I
>> find this less confusing than having the contents of the variables
>> window come and go as you step through the function.  Most of our
>> users seem to agree.
>
> Heck, such a feature will immediately fix:
>
>     http://bugs.kde.org/show_bug.cgi?id=120439
>
> Is this patch available on some branch in the public CVS repository?

No, it is just in the Apple sources.  You can get these from the  
apple opensource repository:

cvs -d pserver:anonymous@anoncvs.opensource.apple.com:/cvs/root co gdb

Our current TOT was last sync'ed up with the FSF sources about 6  
months ago.  Note, however, that in the area of variable objects, our  
sources are substantially different from the FSF sources.

Jim


>
> - Volodya

Re: MI: type prefixes for values

[Vladimir Prus]

On Tuesday 21 February 2006 21:13, Jim Ingham wrote:

> > Say, I've created a bunch of variable objects for for local
> > variables. When I
> > leave the function, those variables become invalid. How do you
> > detect this
> > case? Do you have a command '-list-var-objects-that-are-dead', or
> > some other
> > mechanism.
>
> We don't do this in gdb.  Xcode keeps track of which varobj's go with
> which stack frames, and deletes them when appropriate.  You want to
> be a little clever about this, 'cause there's no need to delete the
> varobj's till the function is actually popped off the stack.  You
> might descend into another function then come back to this one, in
> which case the varobj's are still good.

I was thinking about this more, and still not 100% sure how Xcode can do this. 
Do you mean that Xcode takes a stack trace when the varobj was created, and 
deletes varobj whenever it sees that stack became shorter?

The case I'm not sure about is this:

1. main calls 'a' which calls 'b' which bits breakpoint.
2  varobj is created for local var of 'b'
3. Users says 'continue'.
4. 'b' exists and then 'a' calls 'b' again and breakpoint is
   hit again.

However, this second time it's not guaranteed that stack frame of 'b' is at 
the same address as it was the last time -- maybe 'a' has pushed something on 
stack. How do you detect this case?

> Note, however, that the varobj's do remember their frames, so if you
> tried to evaluate one that was no longer on the stack, the varobj
> would report "out of scope".

Would be great to add this in FSF version.

- Volodya

Re: MI: type prefixes for values

[Daniel Jacobowitz]

On Thu, Apr 06, 2006 at 05:03:25PM +0400, Vladimir Prus wrote:
> I was thinking about this more, and still not 100% sure how Xcode can do this. 
> Do you mean that Xcode takes a stack trace when the varobj was created, and 
> deletes varobj whenever it sees that stack became shorter?
> 
> The case I'm not sure about is this:
> 
> 1. main calls 'a' which calls 'b' which bits breakpoint.
> 2  varobj is created for local var of 'b'
> 3. Users says 'continue'.
> 4. 'b' exists and then 'a' calls 'b' again and breakpoint is
>    hit again.
> 
> However, this second time it's not guaranteed that stack frame of 'b' is at 
> the same address as it was the last time -- maybe 'a' has pushed something on 
> stack. How do you detect this case?

Either b's stack frame is at the same address - in which case the
varobj is still valid - or else it isn't, in which case the frame id
has changed.

> > Note, however, that the varobj's do remember their frames, so if you
> > tried to evaluate one that was no longer on the stack, the varobj
> > would report "out of scope".
> 
> Would be great to add this in FSF version.

It's already there:

  /* The frame for this expression */
  struct frame_id frame;

c_value_of_root will always fail if the frame is gone.

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI: type prefixes for values

[Vladimir Prus]

On Thursday 06 April 2006 17:35, Daniel Jacobowitz wrote:
> On Thu, Apr 06, 2006 at 05:03:25PM +0400, Vladimir Prus wrote:
> > I was thinking about this more, and still not 100% sure how Xcode can do
> > this. Do you mean that Xcode takes a stack trace when the varobj was
> > created, and deletes varobj whenever it sees that stack became shorter?
> >
> > The case I'm not sure about is this:
> >
> > 1. main calls 'a' which calls 'b' which bits breakpoint.
> > 2  varobj is created for local var of 'b'
> > 3. Users says 'continue'.
> > 4. 'b' exists and then 'a' calls 'b' again and breakpoint is
> >    hit again.
> >
> > However, this second time it's not guaranteed that stack frame of 'b' is
> > at the same address as it was the last time -- maybe 'a' has pushed
> > something on stack. How do you detect this case?
>
> Either b's stack frame is at the same address - in which case the
> varobj is still valid - or else it isn't, in which case the frame id
> has changed.

I did not know that GDB exposes frame ID in any way, and Jim has mentioned 
that it's XCode that does the magic, not gdb. Is there some command to print 
frame id that I've missed?

> > > Note, however, that the varobj's do remember their frames, so if you
> > > tried to evaluate one that was no longer on the stack, the varobj
> > > would report "out of scope".
> >
> > Would be great to add this in FSF version.
>
> It's already there:
>
>   /* The frame for this expression */
>   struct frame_id frame;
>
> c_value_of_root will always fail if the frame is gone.

Sorry, does not seems to work this way here. For the following program: 

  void foo()
  {
      int i = 10;
      ++i;
  }

  int main()
  {
      foo();
  }

I get this session:

    (gdb)
    -break-insert a.cpp:5
    ^done,bkpt={......
    (gdb)
    -exec-run
    ^running
    (gdb)
    *stopped,reason="breakpoint-hit",frame={addr="0x080483a1",func="foo"
    (gdb)
    -var-create TMP * i
    ^done,name="TMP",numchild="0",type="int"
    (gdb)
    -var-evaluate-expression TMP
    ^done,value="10"
    (gdb)
    -exec-finish
    ^running
    (gdb)
    *stopped,reason="function-finished",frame={addr="0x080483bd",func="main",
    (gdb)
    -var-evaluate-expression TMP
    ^done,value="10"
    (gdb)

There's no indication that 'TMP' varobj belongs to the stack frame we've 
already left. This is with vanilla 6.4.

- Volodya

Re: MI: type prefixes for values

[Daniel Jacobowitz]

On Thu, Apr 06, 2006 at 05:45:16PM +0400, Vladimir Prus wrote:
> > Either b's stack frame is at the same address - in which case the
> > varobj is still valid - or else it isn't, in which case the frame id
> > has changed.
> 
> I did not know that GDB exposes frame ID in any way, and Jim has mentioned 
> that it's XCode that does the magic, not gdb. Is there some command to print 
> frame id that I've missed?

There shouldn't be, but GDB will notice if the varobj has gone invalid.

>     -exec-finish
>     ^running
>     (gdb)
>     *stopped,reason="function-finished",frame={addr="0x080483bd",func="main",
>     (gdb)
>     -var-evaluate-expression TMP
>     ^done,value="10"
>     (gdb)
> 
> There's no indication that 'TMP' varobj belongs to the stack frame we've 
> already left. This is with vanilla 6.4.

Interesting, the check isn't on this path.  I wonder if we really need
both different ways to get at the value of a variable.  varobj_update
uses value_of_root, but -var-evaluate-expression uses
value_of_variable.  I bet we have some redundant code here.  Maybe not,
value_of_variable is only used for strings, the others work on struct
value.

Anyway:

-var-update *
^done,changelist=[{name="TMP",in_scope="false"}]

There's your out of scope marker.

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI: type prefixes for values

[Vladimir Prus]

On Thursday 06 April 2006 18:01, Daniel Jacobowitz wrote:

> >     -exec-finish
> >     ^running
> >     (gdb)
> >    
> > *stopped,reason="function-finished",frame={addr="0x080483bd",func="main",
> > (gdb)
> >     -var-evaluate-expression TMP
> >     ^done,value="10"
> >     (gdb)
> >
> > There's no indication that 'TMP' varobj belongs to the stack frame we've
> > already left. This is with vanilla 6.4.
>
> Interesting, the check isn't on this path.  I wonder if we really need
> both different ways to get at the value of a variable.  varobj_update
> uses value_of_root, but -var-evaluate-expression uses
> value_of_variable.  I bet we have some redundant code here.  Maybe not,
> value_of_variable is only used for strings, the others work on struct
> value.

I don't quite understand if you're saying that the current behaviour is a bug, 
or not. Can you clarify?

> Anyway:
>
> -var-update *
> ^done,changelist=[{name="TMP",in_scope="false"}]
>
> There's your out of scope marker.

Yes, this is indeed what I'm after. However, now there's reverse problem. Say 
I create variable object for variable 'i'. Then during stepping I enter 
function that also has variable 'i'. I need to detect, somehow, that 'i' 
varobj created earlier relates to the parent stack frame, not the current, 
and that I have to create new variable object.

How do I do that? Using -var-update does not seem to produce this information? 
Am I supposed to manually keep track of frame-id where variable object was 
created? And if so, how do I get frame-id?

- Volodya

Re: MI: type prefixes for values

[Daniel Jacobowitz]

On Thu, Apr 06, 2006 at 06:31:24PM +0400, Vladimir Prus wrote:
> > > There's no indication that 'TMP' varobj belongs to the stack frame we've
> > > already left. This is with vanilla 6.4.
> >
> > Interesting, the check isn't on this path.  I wonder if we really need
> > both different ways to get at the value of a variable.  varobj_update
> > uses value_of_root, but -var-evaluate-expression uses
> > value_of_variable.  I bet we have some redundant code here.  Maybe not,
> > value_of_variable is only used for strings, the others work on struct
> > value.
> 
> I don't quite understand if you're saying that the current behaviour is a bug, 
> or not. Can you clarify?

I don't know.  It's an interface.

Maybe it is an error for you to try to evaluate something after
-var-update says it has gone out of scope.

Maybe -var-evaluate-expression should report not in scope.

Someone with more MI experience would have to decide.

> Yes, this is indeed what I'm after. However, now there's reverse problem. Say 
> I create variable object for variable 'i'. Then during stepping I enter 
> function that also has variable 'i'. I need to detect, somehow, that 'i' 
> varobj created earlier relates to the parent stack frame, not the current, 
> and that I have to create new variable object.
> 
> How do I do that? Using -var-update does not seem to produce this information? 
> Am I supposed to manually keep track of frame-id where variable object was 
> created? And if so, how do I get frame-id?

I don't know.  Maybe Jim will comment.

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI: type prefixes for values

[Jim Ingham]

On Apr 6, 2006, at 6:45 AM, Vladimir Prus wrote:

> On Thursday 06 April 2006 17:35, Daniel Jacobowitz wrote:
>> On Thu, Apr 06, 2006 at 05:03:25PM +0400, Vladimir Prus wrote:
>>> I was thinking about this more, and still not 100% sure how Xcode  
>>> can do
>>> this. Do you mean that Xcode takes a stack trace when the varobj was
>>> created, and deletes varobj whenever it sees that stack became  
>>> shorter?
>>>
>>> The case I'm not sure about is this:
>>>
>>> 1. main calls 'a' which calls 'b' which bits breakpoint.
>>> 2  varobj is created for local var of 'b'
>>> 3. Users says 'continue'.
>>> 4. 'b' exists and then 'a' calls 'b' again and breakpoint is
>>>    hit again.
>>>
>>> However, this second time it's not guaranteed that stack frame of  
>>> 'b' is
>>> at the same address as it was the last time -- maybe 'a' has pushed
>>> something on stack. How do you detect this case?
>>
>> Either b's stack frame is at the same address - in which case the
>> varobj is still valid - or else it isn't, in which case the frame id
>> has changed.
>
> I did not know that GDB exposes frame ID in any way, and Jim has  
> mentioned
> that it's XCode that does the magic, not gdb. Is there some command  
> to print
> frame id that I've missed?

gdb does know what stack frame a variable is bound to.  But gdb  
doesn't do any cleanup of variable objects on it's own.  That's up to  
the MI client.  I am pretty sure that is what I was referring to.

>
>>>> Note, however, that the varobj's do remember their frames, so if  
>>>> you
>>>> tried to evaluate one that was no longer on the stack, the varobj
>>>> would report "out of scope".
>>>
>>> Would be great to add this in FSF version.
>>
>> It's already there:
>>
>>   /* The frame for this expression */
>>   struct frame_id frame;
>>
>> c_value_of_root will always fail if the frame is gone.
>
> Sorry, does not seems to work this way here. For the following  
> program:
>
>   void foo()
>   {
>       int i = 10;
>       ++i;
>   }
>
>   int main()
>   {
>       foo();
>   }
>
> I get this session:
>
>     (gdb)
>     -break-insert a.cpp:5
>     ^done,bkpt={......
>     (gdb)
>     -exec-run
>     ^running
>     (gdb)
>     *stopped,reason="breakpoint-hit",frame= 
> {addr="0x080483a1",func="foo"
>     (gdb)
>     -var-create TMP * i
>     ^done,name="TMP",numchild="0",type="int"
>     (gdb)
>     -var-evaluate-expression TMP
>     ^done,value="10"
>     (gdb)
>     -exec-finish
>     ^running
>     (gdb)
>     *stopped,reason="function-finished",frame= 
> {addr="0x080483bd",func="main",
>     (gdb)
>     -var-evaluate-expression TMP
>     ^done,value="10"
>     (gdb)
>
> There's no indication that 'TMP' varobj belongs to the stack frame  
> we've
> already left. This is with vanilla 6.4.
>

-var-evaluate-expression just fetches the data for the expression as  
it was last computed.  As such, it doesn't know in or out of scope.   
It's -var-update, which recomputes the variable's value.  So if you  
add on to your example:

-var-update TMP
^done,changelist=[varobj={name="TMP",in_scope="false"}]

This is for the Apple gdb, BTW, I don't have a Linux box handy so I'm  
not sure what the FSF gdb would print out, but the logic would be the  
same.

Jim

Re: MI: type prefixes for values

[Daniel Jacobowitz]

On Thu, Apr 06, 2006 at 09:06:14AM -0700, Jim Ingham wrote:
> -var-evaluate-expression just fetches the data for the expression as  
> it was last computed.  As such, it doesn't know in or out of scope.   

I can see, from careful inspection, that this is true.  It surprised
the heck out of me.  I'd have expected it to evaluate it now, not to
return the last evaluated value.

Should it do this?  If so, we should fix the manual.

Eek!  Every call to c_value_of_root for a local changes the selected
frame and reinitializes the frame cache, discarding previous
unwindings.  That's awful.  I sure hope it isn't necessary.

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI: type prefixes for values

[Jim Ingham]

On Apr 6, 2006, at 9:19 AM, Daniel Jacobowitz wrote:

> On Thu, Apr 06, 2006 at 09:06:14AM -0700, Jim Ingham wrote:
>> -var-evaluate-expression just fetches the data for the expression as
>> it was last computed.  As such, it doesn't know in or out of scope.
>
> I can see, from careful inspection, that this is true.  It surprised
> the heck out of me.  I'd have expected it to evaluate it now, not to
> return the last evaluated value.
>
> Should it do this?  If so, we should fix the manual.

I think the idea here was that if you wanted you could use varobj's  
as "history" if you wanted to.  It is also might be convenient that  
if you are using one varobj to display a value in a number of places  
in the UI you don't have to re-evaluate it every time.  But to tell  
the truth, I don't think either of these features is used in Xcode or  
in Insight either, IIRC.

>
> Eek!  Every call to c_value_of_root for a local changes the selected
> frame and reinitializes the frame cache, discarding previous
> unwindings.  That's awful.  I sure hope it isn't necessary.

That looks like that's been there for a long time.  I am not sure why  
it is necessary.  It doesn't cause as much problem as you would  
expect, since in common practice, you get the stack, and display  
that, then just noodle around in the variables on the bottom of the  
stack.  But you're right, it would be good not to do this.  I'll try  
taking it out, and see what happens under Xcode.

Jim


>
> -- 
> Daniel Jacobowitz
> CodeSourcery

Re: MI: type prefixes for values

[Jim Ingham]

On Apr 6, 2006, at 7:41 AM, Daniel Jacobowitz wrote:

> On Thu, Apr 06, 2006 at 06:31:24PM +0400, Vladimir Prus wrote:
>>>> There's no indication that 'TMP' varobj belongs to the stack  
>>>> frame we've
>>>> already left. This is with vanilla 6.4.
>>>
>>> Interesting, the check isn't on this path.  I wonder if we really  
>>> need
>>> both different ways to get at the value of a variable.   
>>> varobj_update
>>> uses value_of_root, but -var-evaluate-expression uses
>>> value_of_variable.  I bet we have some redundant code here.   
>>> Maybe not,
>>> value_of_variable is only used for strings, the others work on  
>>> struct
>>> value.
>>
>> I don't quite understand if you're saying that the current  
>> behaviour is a bug,
>> or not. Can you clarify?
>
> I don't know.  It's an interface.
>
> Maybe it is an error for you to try to evaluate something after
> -var-update says it has gone out of scope.
>
> Maybe -var-evaluate-expression should report not in scope.
>
> Someone with more MI experience would have to decide.

I don't know why it was originally done this way.  But in practice it  
doesn't much matter.  The separation between "update" and "evaluate"  
is useful, since "what's changed" and "give me a value" are questions  
you want to ask separately.  Since the UI generally knows what it  
wants to fetch, having -var-evaluate-expression error if the varobj  
was out of scope hasn't been a big deal in practice.

>
>> Yes, this is indeed what I'm after. However, now there's reverse  
>> problem. Say
>> I create variable object for variable 'i'. Then during stepping I  
>> enter
>> function that also has variable 'i'. I need to detect, somehow,  
>> that 'i'
>> varobj created earlier relates to the parent stack frame, not the  
>> current,
>> and that I have to create new variable object.

>>
>> How do I do that? Using -var-update does not seem to produce this  
>> information?
>> Am I supposed to manually keep track of frame-id where variable  
>> object was
>> created? And if so, how do I get frame-id?
>
> I don't know.  Maybe Jim will comment.

One of the changes that I made early on when we started using the MI  
seriously for Xcode was to add an option to -stack-list-locals and - 
stack-list-args to make varobj's for all the locals/args.  We always  
use these commands to get the varobj's that correspond to the stack  
frame.  Then it is a simple matter in the UI to tie these variable  
objects to their frames, and update, evaluate, whatever, them as  
appropriate for the frame the user is currently looking at.

I think it's a lot easier doing it this way than having an option in  
the MI to report the varobj's frame, and then having to check that  
against the stack each time.

The other bit involved here is that Xcode does keep track of the last  
stack and compares it against the current stack every time you stop.   
That way it knows which frames it does or doesn't have to create new  
variable objects for.

Jim



>
> -- 
> Daniel Jacobowitz
> CodeSourcery

Re: MI: type prefixes for values

[Jim Ingham]

On Apr 6, 2006, at 6:03 AM, Vladimir Prus wrote:

> On Tuesday 21 February 2006 21:13, Jim Ingham wrote:
>
>>> Say, I've created a bunch of variable objects for for local
>>> variables. When I
>>> leave the function, those variables become invalid. How do you
>>> detect this
>>> case? Do you have a command '-list-var-objects-that-are-dead', or
>>> some other
>>> mechanism.
>>
>> We don't do this in gdb.  Xcode keeps track of which varobj's go with
>> which stack frames, and deletes them when appropriate.  You want to
>> be a little clever about this, 'cause there's no need to delete the
>> varobj's till the function is actually popped off the stack.  You
>> might descend into another function then come back to this one, in
>> which case the varobj's are still good.
>
> I was thinking about this more, and still not 100% sure how Xcode  
> can do this.
> Do you mean that Xcode takes a stack trace when the varobj was  
> created, and
> deletes varobj whenever it sees that stack became shorter?

>
> The case I'm not sure about is this:
>
> 1. main calls 'a' which calls 'b' which bits breakpoint.
> 2  varobj is created for local var of 'b'
> 3. Users says 'continue'.
> 4. 'b' exists and then 'a' calls 'b' again and breakpoint is
>    hit again.
>
> However, this second time it's not guaranteed that stack frame of  
> 'b' is at
> the same address as it was the last time -- maybe 'a' has pushed  
> something on
> stack. How do you detect this case?
>


I said this in another response, but to be clear, Xcode stores the  
frame_id's from each stack frame when it stops.  It holds onto this,  
and when it stops again it checks this fingerprint against the new  
frame id's, and the throws away all the varobj's from the point the  
frame_id's vary on to the bottom of stack.  There's no ambiguity if  
you do this.

Jim


>> Note, however, that the varobj's do remember their frames, so if you
>> tried to evaluate one that was no longer on the stack, the varobj
>> would report "out of scope".
>
> Would be great to add this in FSF version.
>
> - Volodya

Re: MI: type prefixes for values

[Vladimir Prus]

On Thursday 06 April 2006 20:53, Jim Ingham wrote:

> > The case I'm not sure about is this:
> >
> > 1. main calls 'a' which calls 'b' which bits breakpoint.
> > 2  varobj is created for local var of 'b'
> > 3. Users says 'continue'.
> > 4. 'b' exists and then 'a' calls 'b' again and breakpoint is
> >    hit again.
> >
> > However, this second time it's not guaranteed that stack frame of
> > 'b' is at
> > the same address as it was the last time -- maybe 'a' has pushed
> > something on
> > stack. How do you detect this case?
>
> I said this in another response, but to be clear, Xcode stores the
> frame_id's from each stack frame when it stops.  It holds onto this,
> and when it stops again it checks this fingerprint against the new
> frame id's, and the throws away all the varobj's from the point the
> frame_id's vary on to the bottom of stack.  There's no ambiguity if
> you do this.

Then, Xcode has to get frame_id of the current frame from gdb, right? Where 
frame is is (stack address + code address). The code address is readily 
available, but I see no way to get stack address. Is that something you've 
added?

- Volodya

Re: MI: type prefixes for values

[Jim Ingham]

Yes, it looks like we added that.  Our -stack-list-frames looks like:

553^done,stack=[frame= 
{level="0",addr="0x00003db0",fp="0xbffff2c0",func="main",file="/ 
private/nfsroot/Users/jingham/Projects/ManyThreads/main.m",fullname="/ 
private/nfsroot/Users/jingham/Projects/ManyThreads/ 
main.m",line="64",dir="/private/nfsroot/Users/jingham/Projects/ 
ManyThreads/"}]


Jim

On Apr 6, 2006, at 10:54 PM, Vladimir Prus wrote:

> On Thursday 06 April 2006 20:53, Jim Ingham wrote:
>
>>> The case I'm not sure about is this:
>>>
>>> 1. main calls 'a' which calls 'b' which bits breakpoint.
>>> 2  varobj is created for local var of 'b'
>>> 3. Users says 'continue'.
>>> 4. 'b' exists and then 'a' calls 'b' again and breakpoint is
>>>    hit again.
>>>
>>> However, this second time it's not guaranteed that stack frame of
>>> 'b' is at
>>> the same address as it was the last time -- maybe 'a' has pushed
>>> something on
>>> stack. How do you detect this case?
>>
>> I said this in another response, but to be clear, Xcode stores the
>> frame_id's from each stack frame when it stops.  It holds onto this,
>> and when it stops again it checks this fingerprint against the new
>> frame id's, and the throws away all the varobj's from the point the
>> frame_id's vary on to the bottom of stack.  There's no ambiguity if
>> you do this.
>
> Then, Xcode has to get frame_id of the current frame from gdb,  
> right? Where
> frame is is (stack address + code address). The code address is  
> readily
> available, but I see no way to get stack address. Is that something  
> you've
> added?
>
> - Volodya

Re: MI: type prefixes for values

[Vladimir Prus]

On Friday 07 April 2006 21:37, Jim Ingham wrote:
> Yes, it looks like we added that.  Our -stack-list-frames looks like:
>
> 553^done,stack=[frame=
> {level="0",addr="0x00003db0",fp="0xbffff2c0",func="main",file="/
> private/nfsroot/Users/jingham/Projects/ManyThreads/main.m",fullname="/
> private/nfsroot/Users/jingham/Projects/ManyThreads/
> main.m",line="64",dir="/private/nfsroot/Users/jingham/Projects/
> ManyThreads/"}]

Hi Jim,
I've now got one last questions. Why do you do this managements of variable 
objects in XCode, and not on gdb side, using -var-update?

If I understand correctly, each time program stops, we need to know for each 
variable object if:

   - it's still alive (containing frame has not exited)
   - changed the value
   - is in different frame from the current (when we enter the function)
   - if the expression variable object was created with refers to 
     different variables now (say, if you created varobj for global 'i',
     now just entered a block containing local 'i').

In mainline, -var-update handles the first two points already. It's possible 
to support third point easily. I'm not sure about the fourth.

So, why did you decide to handle varobj lifetime in XCode, and not in gdb? 

Thanks,
Volodya

Re: MI: type prefixes for values

[Jim Ingham]

On Apr 12, 2006, at 4:37 AM, Vladimir Prus wrote:

> On Friday 07 April 2006 21:37, Jim Ingham wrote:
>> Yes, it looks like we added that.  Our -stack-list-frames looks like:
>>
>> 553^done,stack=[frame=
>> {level="0",addr="0x00003db0",fp="0xbffff2c0",func="main",file="/
>> private/nfsroot/Users/jingham/Projects/ManyThreads/ 
>> main.m",fullname="/
>> private/nfsroot/Users/jingham/Projects/ManyThreads/
>> main.m",line="64",dir="/private/nfsroot/Users/jingham/Projects/
>> ManyThreads/"}]
>
> Hi Jim,
> I've now got one last questions. Why do you do this managements of  
> variable
> objects in XCode, and not on gdb side, using -var-update?
>
> If I understand correctly, each time program stops, we need to know  
> for each
> variable object if:
>
>    - it's still alive (containing frame has not exited)
>    - changed the value
>    - is in different frame from the current (when we enter the  
> function)
>    - if the expression variable object was created with refers to
>      different variables now (say, if you created varobj for global  
> 'i',
>      now just entered a block containing local 'i').
>
> In mainline, -var-update handles the first two points already. It's  
> possible
> to support third point easily. I'm not sure about the fourth.
>
> So, why did you decide to handle varobj lifetime in XCode, and not  
> in gdb?

Xcode already has to manage the coming & going of frames.  After all,  
it would be inefficient if you had to flush & remake Xcode's  
representation of the stack every time you stepped.  It's actually  
pretty important to do as little as possible on each step, this is  
one of the performance-critical areas of a GUI debugger.  N.B. you  
don't have to worry about this in gdb, because the stack is only  
presented on demand, but in a UI it's always visible so you HAVE to  
refresh it every time you stop.  So having Xcode handle the frame- 
tied varobj's lifetimes seemed more natural.

Also, I think it's a clearer architecture for the UI to own the  
things it creates in gdb, and only have them go away when it tells  
them to.  After all, the UI is going to have to handle the lifetimes  
of its side of the variable object.  So it's more natural for it to  
handle the gdb side as well.  That reduces the chance for surprise.   
The object can and should be able to say it's gone out of scope, in  
case the UI gets confused for some reason.  But it shouldn't go away.

Jim

Re: MI: type prefixes for values

[Vladimir Prus]

On Wednesday 12 April 2006 20:55, Jim Ingham wrote:
> On Apr 12, 2006, at 4:37 AM, Vladimir Prus wrote:
> > On Friday 07 April 2006 21:37, Jim Ingham wrote:
> >> Yes, it looks like we added that.  Our -stack-list-frames looks like:
> >>
> >> 553^done,stack=[frame=
> >> {level="0",addr="0x00003db0",fp="0xbffff2c0",func="main",file="/
> >> private/nfsroot/Users/jingham/Projects/ManyThreads/
> >> main.m",fullname="/
> >> private/nfsroot/Users/jingham/Projects/ManyThreads/
> >> main.m",line="64",dir="/private/nfsroot/Users/jingham/Projects/
> >> ManyThreads/"}]
> >

> > So, why did you decide to handle varobj lifetime in XCode, and not
> > in gdb?
>
> Xcode already has to manage the coming & going of frames.  After all,
> it would be inefficient if you had to flush & remake Xcode's
> representation of the stack every time you stepped.  It's actually
> pretty important to do as little as possible on each step, this is
> one of the performance-critical areas of a GUI debugger.  N.B. you
> don't have to worry about this in gdb, because the stack is only
> presented on demand, but in a UI it's always visible so you HAVE to
> refresh it every time you stop.  So having Xcode handle the frame-
> tied varobj's lifetimes seemed more natural.

You mean, you don't get full stack trace on each step, but only when current 
frame_id changes? Pretty smart!

> Also, I think it's a clearer architecture for the UI to own the
> things it creates in gdb, and only have them go away when it tells
> them to.  After all, the UI is going to have to handle the lifetimes
> of its side of the variable object.  So it's more natural for it to
> handle the gdb side as well.  That reduces the chance for surprise.
> The object can and should be able to say it's gone out of scope, in
> case the UI gets confused for some reason.  But it shouldn't go away.

Well, handling frames on frontend side seems clearer to me too.

- Volodya