Re: MI: performance of getting stack arguments

Robert Dewar
2006-04-18T21:35:08Z

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