This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [PATCH] -stack-select-frame
[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.
> (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="1118952348.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?
Nick