This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Type information in -data-evaluate-expression
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'