Re: [PATCH] -stack-select-frame

[Jim Ingham <jingham@apple.com>]

On Jun 17, 2005, at 3:15 AM, gdb-patches-digest- 
help@sources.redhat.com wrote:

>
>
>
> [Jason - Sorry if you get this twice.  My first message bounced at  
> RedHat, for
> some reason.]
>
>
>>> I thought it would save some time if the user doesn't need to see  
>>> the
>>> whole stack.
>>>
>>
>> FWIW we've done a lot of careful timing analysis, and the back &
>> forth communication between our GUI and gdb is so fast as to be
>> pointless to optimize.  We original considered adding special purpose
>> "give Xcode everything it needs to know at a breakpoint hit" type
>> commands but when we saw how fast the majority of MI commands can
>> execute & be parsed by the GUI, it was obvious that this was not a
>> useful area to optimize.  And frankly, in my anecdotal experience,
>> MacOS X isn't the fastest OS at things like "two processes talking
>> over a pipe".
>>
>
> You've clearly been more quantitative.  With my limited resources, I'm
> just guessing what might work best.  I've suggested to Daniel a change
> that, I hope, won't impact on Xcode.  I think you have your own copy
> of GDB and, like you say, you don't really care, but I guess its best
> not to diverge more than necessary.

Yes, thats right.  We would rather not introduce gratuitous divergences.

>
>
>> (one of the parts of this profiling which is especially useful is
>> that we have a "mi-timings-enabled" setting.  When it's enabled,
>> every MI command reports how long gdb took to complete it, e.g. the
>> "time=" bit at the end here:
>>
>> -> 50-stack-list-frames 0 5
>> <- 50^done,stack=[frame=
>> {level="0",addr="0x0009e7fc",fp="0xbfffe700",func=" [...] ,frame=
>> {level="5",addr="0x936265d0",fp="0xbfffeee0",func="-[NSApplication
>> run]"}],time=
>> {wallclock="0.14353",user="0.00584",system="0.00335",start="111895234 
>> 8.0
>> 03847",end="1118952348.147372"}
>>
>
> Yes but what happens when the stack is much deeper, 20 or 30 say,  
> like it can
> be when you you are debugging Emacs, or GDB for that matter?


You are right to worry about this a bit.  Getting a full backtrace  
when the stack is deep can be expensive, especially when you do it  
every step.  And using a complex kit like AppKit or Carbon where lots  
of the work is done through callbacks, etc, can lead to really deep  
stacks as well.  OTOH, the stack window is sitting there open, so we  
have to keep it up to date.  We got hit with this pretty early on in  
getting Xcode working.

What we did was add another command (-stack-list-frames-lite) that  
just returns the pairs (pc/sp) for the current stack.  You can  
usually implement this to run quite quickly on the target side  
without having to do the full register unwind, etc (*).  Then every  
time we stop, Xcode calls this -stack-list-frames-lite, and compares  
the results with the stack it had before the target started up.  Then  
it only needs to fetch the frames that have changed.  For extra  
credit, it could not fetch the frames for any that aren't visible in  
the current stack window in the GUI, though Xcode hasn't done that yet.

We still pay a cost when you arrive in a totally new stack.  But  
since the target usually has to run a bit for the stack to change a  
lot, this cost gets mixed in with the target running, and doesn't  
create such a bad perceived slowness.  But it removes most of the  
problems that stack tracing gave us when stepping, which is where a  
lag really annoys users.


(*) I think Andrew's design of the frame caching stuff should make  
this unnecessary if the architecture specific unwinders were smart  
enough to only unwind the one register they were asked to every  
time.  We haven't done that yet, but that's more an implememtation  
detail.

Jim


>
> Nick
>