MI: performance of getting stack arguments

[Robert Dewar]

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