Type information in -data-evaluate-expression

Type information in -data-evaluate-expression

[André Pönitz]

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


Hi all.

While playing around with gdb's "mi" interface (which looks rather
nice for scripting btw...) I came across a few places where I think
the interface might be made even more convienient without much
effort.

One example: As far as I can see currently the only way to obtain 
the type of an expression is to use -var-create & -var-delete.
It would be more convienient for me if I could get that information
with a single command without creating a variable which will be
thrown away immediatedly afterwards.

A possibility to do so would be to "enhance" "-data-evaluate-expression"
to return not only the value, but also the type information which is
is available after the evaluation process anyway.

I came up with a tiny patch that "seem to work for me". But as this
is the first time I look gdb source I am unsure whether this is done
properly or if some kind of cleanup is needed, and, of course, whether
there is a chance to get such patches included in gdb proper
at some point of time.

Andre'

[-- Attachment #2: t --]
[-- Type: text/x-diff, Size: 536 bytes --]

Index: mi-main.c
===================================================================
RCS file: /cvs/src/src/gdb/mi/mi-main.c,v
retrieving revision 1.100
diff -u -r1.100 mi-main.c
--- mi-main.c	16 Jun 2007 17:16:26 -0000	1.100
+++ mi-main.c	30 Jul 2007 13:08:51 -0000
@@ -706,6 +706,11 @@
 	     stb->stream, 0, 0, 0, 0);
 
   ui_out_field_stream (uiout, "value", stb);
+
+  type_print (value_type (val), "", stb->stream, -1);
+
+  ui_out_field_stream (uiout, "type", stb);
+
   ui_out_stream_delete (stb);
 
   do_cleanups (old_chain);

Re: Type information in -data-evaluate-expression

[Vladimir Prus]

André Pönitz wrote:

> 
> Hi all.
> 
> While playing around with gdb's "mi" interface (which looks rather
> nice for scripting btw...) I came across a few places where I think
> the interface might be made even more convienient without much
> effort.
> 
> One example: As far as I can see currently the only way to obtain
> the type of an expression is to use -var-create & -var-delete.
> It would be more convienient for me if I could get that information
> with a single command without creating a variable which will be
> thrown away immediatedly afterwards.

What is the use case where you need to just get the type of an expression,
without doing anything with it?

> A possibility to do so would be to "enhance" "-data-evaluate-expression"
> to return not only the value, but also the type information which is
> is available after the evaluation process anyway.
> 
> I came up with a tiny patch that "seem to work for me". But as this
> is the first time I look gdb source I am unsure whether this is done
> properly or if some kind of cleanup is needed, and, of course, whether
> there is a chance to get such patches included in gdb proper
> at some point of time.

I'd expect this patch will break a bunch of tests, since those tests
are not expecting the additional 'type' field. The patch itself
seems reasonable as far as code is concerned, but I'm not yet sure about
your use case. I'd prefer -data-evaluate-expression to fall to misuse,
rather than adding some new functionality to it.

- Volodya

Re: Type information in -data-evaluate-expression

[André Pönitz]

On Monday 30 July 2007 15:52:10 Vladimir Prus wrote:
> André Pönitz wrote:
> > While playing around with gdb's "mi" interface (which looks rather
> > nice for scripting btw...) I came across a few places where I think
> > the interface might be made even more convienient without much
> > effort.
> > 
> > One example: As far as I can see currently the only way to obtain
> > the type of an expression is to use -var-create & -var-delete.
> > It would be more convienient for me if I could get that information
> > with a single command without creating a variable which will be
> > thrown away immediatedly afterwards.
> 
> What is the use case where you need to just get the type of an expression,
> without doing anything with it?

One use case would be to display values in a graphical frontend
when hovering (or even moving) the mouse over some expression.
My current "best practice" here is to create a variable called "tooltip",
extract value and type and delete it again, only to create it again
with a slightly different expression etc. So I need two roundtrips
and need some syncronization to handle the two partial results
whereas the proposed "enhanced" version would allow a simple
hit-and-run implementation...

Also, there are times when I would like to call "custom data dumpers"
(think std::string or std::vector) instead of using the content of the 
value field. To trigger those dumpers quickly I need to get hold of type
information quickly, preferably after the first round trip. I understand that
a delay of a few dozen milliseconds for a round trip is a non-issue for
the typical command line use, however these add up easily to a more
significant amount if one "needs" lots of them...

> [...] I'd expect this patch will break a bunch of tests, since those tests
> are not expecting the additional 'type' field. 

mi2-eval.exp and mi-eval.exp seems to be affected, I guess I would
be able to fix them.

> The patch itself seems reasonable as far as code is concerned, but
> I'm not yet sure about your use case.
> I'd prefer -data-evaluate-expression to fall to misuse, 
> rather than adding some new functionality to it.

The gdb variable business requires some bookkeeping on the frontend
side some of which I'd like to avoid.

Andre'

Re: Type information in -data-evaluate-expression

[Nick Roberts]

 > > What is the use case where you need to just get the type of an expression,
 > > without doing anything with it?
 > 
 > One use case would be to display values in a graphical frontend
 > when hovering (or even moving) the mouse over some expression.
 > My current "best practice" here is to create a variable called "tooltip",
 > extract value and type and delete it again, only to create it again
 > with a slightly different expression etc. So I need two roundtrips
 > and need some syncronization to handle the two partial results
 > whereas the proposed "enhanced" version would allow a simple
 > hit-and-run implementation...

What happens if you have compiled with "-g3", have the line

#define STOP abort ()

in your code and the mouse hovers over STOP?

Also do the values of large arrays/structures appear as large tooltips?

Around the end of last year there was a discussion on gdb-patches (Re: variable
objects and registers) about using variable objects for tooltips.  Jim
Ingham said that Apple currently do this for Xcode and it works well.  I think
we should explore this possibility and perhaps review their code.

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

Re: Type information in -data-evaluate-expression

[Nick Roberts]

[please CC the mailing list]

 > > What happens if you have compiled with "-g3", have the line
 > >
 > > #define STOP abort ()
 > > 
 > > in your code and the mouse hovers over STOP?
 > 
 > It will say "STOP = No symbol STOP in current context". That's what it does
 > right now, I just checked.

I guess that just means your your executable doesn't provide macro information.
"info source" should give something like:

  Current source file is myprog.c
  Compilation directory is /home/nickrob
  Located in /home/nickrob/myprog.c
  Contains 160 lines.
  Source language is c.
  Compiled with DWARF 2 debugging format.
  Includes preprocessor macro info.

Perhaps your machine uses stabs.

With macro information I would expect you to get something like:

-data-evaluate-expression STOP
&"The program being debugged was signaled while in a function called from GDB.\n"
&"GDB remains in the frame where the signal was received.\n"
&"To change this behavior use \"set unwindonsignal on\"\n"
&"Evaluation of the expression containing the function (abort) will be abandoned.\n"
^error,msg="The program being debugged was signaled while in a function called from GDB.\nGDB remains in the frame where the signal was received.\nTo change this behavior use \"set unwindonsignal on\"\nEvaluation of the expression containing the function (abort) will be abandoned."
(gdb) 

 > But yes, I already noticed that passing expressions with side effects
 > sometimes has ...erm... "funny results" which makes me overly restrictive
 > when deciding what expressions are allowed to be evaluated by gdb.
 > 
 > Apart from that I am fairly free to dictate users of "my" applications what
 > to do and what not ;-) If -g3 would turn out to be "problematic" (for
 > whatever value of "problematic" is appropriate in this context), saying "You
 > are on your own when doing that" would be just fine(-ish). There are already
 > tons of much more serious restrictions dictated by hardware, compilers,
 > phase of the moon etc...

Perhaps I've misundsertood, but if others are using your frontend to debug
their applications, they might be a bit irritated if such a message is
triggered by just moving the mouse.

 > > Also do the values of large arrays/structures appear as large tooltips?
 > 
 > No. Top level structure members, possibly with abbreviated values,
 > plus type information. Typical size is 60 x 15 to 120 x 30 pixels which
 > already passed internal usability tests.

That's odd.  I seem to get the first 200 elements of an array when I use
-data-evaluate-expression (or print).  Do you just throw this information
away?

 >  > Around the end of last year there was a discussion on gdb-patches (Re:
 > > variable objects and registers) about using variable objects for tooltips.
 > > Jim Ingham said that Apple currently do this for Xcode and it works well.
 > > I think we should explore this possibility and perhaps review their code.
 > 
 > I am currently using variables as well, and although it works (well even) 
 > it makes me jump through certain hoops which I'd like to avoid.
 > 
 > But if you are not convinced by the use case I gave I could try to describe
 > another: When displaying a local variable of type, say,
 > std::list<std::string> in the customary tree view of "Locals & Watchers" I
 > do not want to see the internals of std::list there but rather the
 > std::string items in the list, and I want them flat in one level (as opposed
 > to some list.next->next->next->data structure). Using gdb variables makes
 > displaying the list.next->next->next->data (or rather some
 > list.private.next.private.next.private.next.private.data item) easy, but to
 > get immediate access using -data-evaluate-expression
 > list[0]...list[list.size() - 1] is much more convienient.

I'm sure you are right that variable objects are far from perfect but maybe
this is an example of where they can be improved rather than a case for
using -data-evaluate-expression.  Perhaps Jim can comment.

Here's another example where tooltips using -data-evaluate-expression might not
work:

  int i;
  i = 1;
  {
    int i;
    i = 10;
=>  i++;
  }

If execution is at the arrow, the user might place the mouse over the first
occurrence of i and expect the value 1 to be displayed.  However, since
-data-evaluate-expression evaluates relative to the current line, 10 would
actually be displayed.

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

Re: Type information in -data-evaluate-expression

[André Pönitz]

On Tuesday 31 July 2007 10:09:36 you wrote:
> [please CC the mailing list]

Sorry, private mail was not intentional.

>  > > What happens if you have compiled with "-g3", have the line
>  > >
>  > > #define STOP abort ()
>  > > 
>  > > in your code and the mouse hovers over STOP?
>  > 
>  > It will say "STOP = No symbol STOP in current context". That's what it does
>  > right now, I just checked.
> 
> I guess that just means your your executable doesn't provide macro information.
> "info source" should give something like:
> 
>   Current source file is myprog.c
>   Compilation directory is /home/nickrob
>   Located in /home/nickrob/myprog.c
>   Contains 160 lines.
>   Source language is c.
>   Compiled with DWARF 2 debugging format.
>   Includes preprocessor macro info.

"Does not include preprocessor macro info."

> Perhaps your machine uses stabs.

> With macro information I would expect you to get something like:
> 
> -data-evaluate-expression STOP
> &"The program being debugged was signaled while in a function called from GDB.\n"
> &"GDB remains in the frame where the signal was received.\n"
> &"To change this behavior use \"set unwindonsignal on\"\n"
> &"Evaluation of the expression containing the function (abort) will be abandoned.\n"
> ^error,msg="The program being debugged was signaled while in a function called from GDB.\nGDB remains in the frame where the signal was received.\nTo change this behavior use \"set unwindonsignal on\"\nEvaluation of the expression containing the function (abort) will be abandoned."
> (gdb) 

Ok, I get this now.

But that's nice. I am running with "set unwindonsignal on" anyway as my 
"custom data dumpers" tend to produce (expectedly so...) segmentation 
faults when being thrown on uninitialized data structures.

So this really does not hurt. I can even call  -data-evaluate-expression
abort() directly and am still able to continue debugging.

>  > But yes, I already noticed that passing expressions with side effects
>  > sometimes has ...erm... "funny results" which makes me overly restrictive
>  > when deciding what expressions are allowed to be evaluated by gdb.
>  > 
>  > Apart from that I am fairly free to dictate users of "my" applications what
>  > to do and what not ;-) If -g3 would turn out to be "problematic" (for
>  > whatever value of "problematic" is appropriate in this context), saying "You
>  > are on your own when doing that" would be just fine(-ish). There are already
>  > tons of much more serious restrictions dictated by hardware, compilers,
>  > phase of the moon etc...
> 
> Perhaps I've misundsertood, but if others are using your frontend to debug
> their applications, they might be a bit irritated if such a message is
> triggered by just moving the mouse.

I am already heavily filtering messages anyway. So this is "just one more"...

>  > > Also do the values of large arrays/structures appear as large tooltips?
>  > 
>  > No. Top level structure members, possibly with abbreviated values,
>  > plus type information. Typical size is 60 x 15 to 120 x 30 pixels which
>  > already passed internal usability tests.
> 
> That's odd.  I seem to get the first 200 elements of an array when I use
> -data-evaluate-expression (or print).  Do you just throw this information
> away?

Most of it, yes.

>  >  > Around the end of last year there was a discussion on gdb-patches (Re:
>  > > variable objects and registers) about using variable objects for tooltips.
>  > > Jim Ingham said that Apple currently do this for Xcode and it works well.
>  > > I think we should explore this possibility and perhaps review their code.
>  > 
>  > I am currently using variables as well, and although it works (well even) 
>  > it makes me jump through certain hoops which I'd like to avoid.
>  > 
>  > But if you are not convinced by the use case I gave I could try to describe
>  > another: When displaying a local variable of type, say,
>  > std::list<std::string> in the customary tree view of "Locals & Watchers" I
>  > do not want to see the internals of std::list there but rather the
>  > std::string items in the list, and I want them flat in one level (as opposed
>  > to some list.next->next->next->data structure). Using gdb variables makes
>  > displaying the list.next->next->next->data (or rather some
>  > list.private.next.private.next.private.next.private.data item) easy, but to
>  > get immediate access using -data-evaluate-expression
>  > list[0]...list[list.size() - 1] is much more convienient.
> 
> I'm sure you are right that variable objects are far from perfect but maybe
> this is an example of where they can be improved rather than a case for
> using -data-evaluate-expression.  Perhaps Jim can comment.

Uh... I see a possible way to improve things, but this would be certainly 
_way_ more intrusive than the proposed two-line addition we are currently 
discussing so extensively ;-)

The idea is to run custom code in certain cases, e.g. when outputting 
"type=foo,value=..." fields one would be able to hook in code which gets
passed type information and start address and some kind of stream to
write to and then _I_ could have my code to output e.g.

  value=[{name="length",type="size_t",value="2005",readonly="true"},
        {name="0",type="std::string",value="first item"},
       ...  {name="2004",type="std::string",value="two thousand and fifth item}]

Unfortunately gdb scripts are ... erm... 'a bit' too slow to provide that
functionality for structures containing more than a handful items, but 
the idea also works with compiled code injected into the debugged process. 
I am doing that currently using dlopen/LoadLibraryA and it "works" (even with 
unitialized objects -- it would btw be really nice if _that_ information were
available without going through segfaults...)

> Here's another example where tooltips using -data-evaluate-expression might not
> work:
> 
>   int i;
>   i = 1;
>   {
>     int i;
>     i = 10;
> =>  i++;
>   }
>
> If execution is at the arrow, the user might place the mouse over the first
> occurrence of i and expect the value 1 to be displayed.  However, since
> -data-evaluate-expression evaluates relative to the current line, 10 would
> actually be displayed.

Right. Living a programmer's life is risky. Computers are lying to you all the time...
[The problem is that s/Computers/Humans/ and s/programmer's/real/ does not
change the truth value at all ;-}]

[Apart from that: My target group prefers getting tooltips that are sometimes (or 
even most of the time) wrong over getting no tooltips at all.]

Andre' 

Re: Type information in -data-evaluate-expression

[Nick Roberts]

 > Ok, I get this now.
 > 
 > But that's nice. I am running with "set unwindonsignal on" anyway as my 
 > "custom data dumpers" tend to produce (expectedly so...) segmentation 
 > faults when being thrown on uninitialized data structures.
 > 
 > So this really does not hurt. I can even call  -data-evaluate-expression
 > abort() directly and am still able to continue debugging.

I guess other unpleasant things could happen, like variables changing value.

 >...
 > Uh... I see a possible way to improve things, but this would be certainly 
 > _way_ more intrusive than the proposed two-line addition we are currently 
 > discussing so extensively ;-)

I'm discussing other, possibly better, alternatives.  I guess there's no harm
in your change as long as you provide a test for the testsuite, documentation,
maintenance etc... but a global maintainer approves the change anyway.

 > The idea is to run custom code in certain cases, e.g. when outputting 
 > "type=foo,value=..." fields one would be able to hook in code which gets
 > passed type information and start address and some kind of stream to
 > write to and then _I_ could have my code to output e.g.
 > 
 >   value=[{name="length",type="size_t",value="2005",readonly="true"},
 >         {name="0",type="std::string",value="first item"},
 >        ...  {name="2004",type="std::string",value="two thousand and fifth item}]
 > 
 > Unfortunately gdb scripts are ... erm... 'a bit' too slow to provide that
 > functionality for structures containing more than a handful items, but 
 > the idea also works with compiled code injected into the debugged process. 
 > I am doing that currently using dlopen/LoadLibraryA and it "works" (even with 
 > unitialized objects -- it would btw be really nice if _that_ information were
 > available without going through segfaults...)

Such a change is way over my head, but GDB runs on many architectures and I
think it would need to be portable.

 >...
 > > If execution is at the arrow, the user might place the mouse over the first
 > > occurrence of i and expect the value 1 to be displayed.  However, since
 > > -data-evaluate-expression evaluates relative to the current line, 10 would
 > > actually be displayed.
 > 
 > Right. Living a programmer's life is risky. Computers are lying to you all
 > the time...  [The problem is that s/Computers/Humans/ and
 > s/programmer's/real/ does not change the truth value at all ;-}]
 > 
 > [Apart from that: My target group prefers getting tooltips that are
 > sometimes (or even most of the time) wrong over getting no tooltips at all.]

Life _is_ risky but, if possible, I still like to improve the odds.

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

Re: Type information in -data-evaluate-expression

[Vladimir Prus]

Nick Roberts wrote:

>  > Ok, I get this now.
>  > 
>  > But that's nice. I am running with "set unwindonsignal on" anyway as my
>  > "custom data dumpers" tend to produce (expectedly so...) segmentation
>  > faults when being thrown on uninitialized data structures.
>  > 
>  > So this really does not hurt. I can even call 
>  > -data-evaluate-expression abort() directly and am still able to
>  > continue debugging.
> 
> I guess other unpleasant things could happen, like variables changing
> value.

So what are you proposing? Variable tooltips is something users like.

- Volodya

Re: Type information in -data-evaluate-expression

[Nick Roberts]

 > >  > So this really does not hurt. I can even call 
 > >  > -data-evaluate-expression abort() directly and am still able to
 > >  > continue debugging.
 > > 
 > > I guess other unpleasant things could happen, like variables changing
 > > value.
 > 
 > So what are you proposing? Variable tooltips is something users like.

I don't think they like variables to change value when they move the
mouse around e.g.

  #define ADD4 addtox (4)

  int x = 1;

  void addtox (int i)
  {
    x = x + i;
  }  

adds 4 to x every time the mouse lingers over ADD4.  It's a contrived example
but there are probably more realistic scenarios.  In Emacs, I don't compute
the tooltip if the macro expands to a function.

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

Re: Type information in -data-evaluate-expression

[Daniel Jacobowitz]

On Tue, Jul 31, 2007 at 10:29:01PM +1200, Nick Roberts wrote:
>  >...
>  > Uh... I see a possible way to improve things, but this would be certainly 
>  > _way_ more intrusive than the proposed two-line addition we are currently 
>  > discussing so extensively ;-)
> 
> I'm discussing other, possibly better, alternatives.  I guess there's no harm
> in your change as long as you provide a test for the testsuite, documentation,
> maintenance etc... but a global maintainer approves the change anyway.

I understand that we'd rather people do complicated things with
varobjs, but displaying the type of one-shot expressions seems
reasonable to me.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Type information in -data-evaluate-expression

[Nick Roberts]

 > I understand that we'd rather people do complicated things with
 > varobjs, but displaying the type of one-shot expressions seems
 > reasonable to me.

This change alone is so small it's harmless.  More generally though, it's less
about doing more complicated things with varobjs and more about not duplicating
effort.  Next time André finds that his tooltips don't work as he would wish,
he will submit another patch for -data-evaluate-expression.  If others are
using variable objects they will see no benefit unless they create a similar
patch.  And the same holds the other way around.


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

Re: Type information in -data-evaluate-expression

[Vladimir Prus]

Nick Roberts wrote:

> Here's another example where tooltips using -data-evaluate-expression
> might not work:
> 
>   int i;
>   i = 1;
>   {
>     int i;
>     i = 10;
> =>  i++;
>   }
> 
> If execution is at the arrow, the user might place the mouse over the
> first
> occurrence of i and expect the value 1 to be displayed.  However, since
> -data-evaluate-expression evaluates relative to the current line, 10 would
> actually be displayed.

Not that it works with variable objects, anyway. OTOH, I think
expanding -var-create so that it takes "context line" where expression
is to be evaluated should be rather simple.

- Volodya


 

Re: Type information in -data-evaluate-expression

[Nick Roberts]

 > > If execution is at the arrow, the user might place the mouse over the
 > > first occurrence of i and expect the value 1 to be displayed.  However,
 > > since -data-evaluate-expression evaluates relative to the current line, 10
 > > would actually be displayed.
 > 
 > Not that it works with variable objects, anyway. OTOH, I think
 > expanding -var-create so that it takes "context line" where expression
 > is to be evaluated should be rather simple.

I think that was what we discussed last time.  That, and the fact that you
could expand structures within the tooltip if they were created from
variable objects:

This is what Jim Ingham said:

  Yup, that's basically what Xcode does.  The guy that did is actually  
  has a pretty cool way of posting the sub-elements in the tooltips.  I  
  can't really describe it - you have to see it - but it's very  
  convenient.


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

Re: Type information in -data-evaluate-expression

[Vladimir Prus]

André Pönitz wrote:

> On Monday 30 July 2007 15:52:10 Vladimir Prus wrote:
>> André Pönitz wrote:
>> > While playing around with gdb's "mi" interface (which looks rather
>> > nice for scripting btw...) I came across a few places where I think
>> > the interface might be made even more convienient without much
>> > effort.
>> > 
>> > One example: As far as I can see currently the only way to obtain
>> > the type of an expression is to use -var-create & -var-delete.
>> > It would be more convienient for me if I could get that information
>> > with a single command without creating a variable which will be
>> > thrown away immediatedly afterwards.
>> 
>> What is the use case where you need to just get the type of an
>> expression, without doing anything with it?
> 
> One use case would be to display values in a graphical frontend
> when hovering (or even moving) the mouse over some expression.
> My current "best practice" here is to create a variable called "tooltip",
> extract value and type and delete it again, only to create it again
> with a slightly different expression etc. So I need two roundtrips
> and need some syncronization to handle the two partial results
> whereas the proposed "enhanced" version would allow a simple
> hit-and-run implementation...

Yes, but in the long run, your frontend will need a mechanism to
handle chain of several commands, anyway. In fact, I think the best
design would be to talk to gdb in a separate thread, so that
you need a straight-forward procedural code, not callback-based code.
At least, that's the design I plan to use in KDevelop4.

> Also, there are times when I would like to call "custom data dumpers"
> (think std::string or std::vector) instead of using the content of the
> value field. To trigger those dumpers quickly I need to get hold of type
> information quickly, preferably after the first round trip. I understand
> that a delay of a few dozen milliseconds for a round trip is a non-issue
> for the typical command line use, however these add up easily to a more
> significant amount if one "needs" lots of them...

If you query the type for expression under cursor, then you have only one
expression, no? Therefore, the difference between 1ms and 2ms is not important.

- Volodya