This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] -stack-select-frame



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




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]