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