This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: MI: performance of getting stack arguments
Jim Ingham wrote:
On Apr 18, 2006, at 12:11 PM, Robert Dewar wrote:
Jim Ingham wrote:
Do you really have a UI that shows the stack arguments for ALL the
frames on the stack? That's very unusual (and visually a bit
overwhelming, I would imagine). The usual stack display shows the
stack with just the function names. Then clicking on any given stack
will populate the arguments for that frame, fill the source window
with the source for that frame, etc... This way, you only need to
fetch the arguments for the bottom-most frame on the stack when you
stop stepping. You would only fetch the other stack arguments if the
user specifically requests them.
The ordinary bt from gdb gives this info, and it would be a pain
not to have it!
I dunno. I find that having a really simple clean stack listing with
just function names makes it much easier to tell where I am in the
program. Most of the time that's what I want to see, not what the third
argument to the function 10 frames up on the stack was. If I want that,
I don't find it a problem to dial it up. And in the GUI all you have to
do is click on the frame to see the source & arguments. This seems to
work pretty well for folks, at least we get lots of suggestions from our
users, but nobody's ever asked us to change this.
Gosh I would find this horrible. For example, a very common thing for
me is to debug a crash in the gigi section of GNAT. I need to quickly
loook down the call stack to find the most recent reference to a
routine with a parameter gnat_node to find the corresponding node
in the front end tree. It would be very painful to iterate frame
by frame to find this.
Anyway, this is a "to each his own" kind of thing. But just keep in
mind, when you are implementing a GUI debugger that anything you show in
the UI you are pledging to update every time a step is completed. And
most folks are pretty sensitive about how long it takes for each step to
complete. So you do need to be a bit conservative about what you display
by default. Adding to this, gdb does get slow as programs get large,
which makes it even more important to be judicious.
Yes, well I agree the GUI requirements are quite different indeed.
I only want to see the call stack when I need it and not all the
time (I don't use a GUI interface to GDB, I prefer to use it in
command line mode).
Also, in a GUI much more stuff is visible at once, so if each element is
too complex then the overall result is noisy and hard to use. Visual
Studio used by default to show a whole bunch of junk in the stack window
(pc, args, etc.) and way back when I used it I found it really hard to
look at for just this reason. According to the 2005 Online docs, you
can turn all the other info off and display just the function name if
you want...
Seems reasonable to have a much more streamlined call stack visible all
the time, and a special command to decorate it with parameter values.
Jim