This is the mail archive of the gdb-patches@sourceware.org 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: [RFC] Prints the frame id when target stops


On Thu, Jan 18, 2007 at 12:46:11AM +0300, Vladimir Prus wrote:
> > The backtrace is different in an interesting way here if you set a
> > breakpoint on foo and continue twice, but if you choose your buffer
> > sizes just right, then you can get the two calls to foo to have the
> > same ID.  If your IDE doesn't refresh its stack display, you're
> > going to have a stale call trace.
> 
> Yes, that's an obvious problem. What makes you think a frontend
> is in better position to fix it?

I don't.  Sorry if I was unclear.

> > Apple implemented a very high performance, light weight unwinder that
> > just does frame IDs - on PPC this happens to be quite easy.  We could
> > make other targets do the same thing.  That probably helps here.
> 
> Just to clarify -- you mean you don't get any function names or
> code lines so you don't have to look in the symbol tables? And
> if this backtrace changes you can get the full backtrace.

Well, you might have to look in the symbol table anyway - I'm not sure
how many shortcuts they take, but normally you'd still need to know
where the start of functions were.  But you don't need line numbers or
other saved registers.  I suspect they just rely on the PPC ABI frame
convention, which is very quick to unwind.  You can do the same thing
more flexibly by caching the result of a prologue analyzer, too.

-- 
Daniel Jacobowitz
CodeSourcery


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