Re: Single step vs. "tail recursion" optimization

[Jim Blandy <jimb at redhat dot com>]

Michael Snyder <msnyder@redhat.com> writes:
> Donn Terry wrote:
> > 
> > (I'm sorry to have to be the messenger on this one...)
> > 
> > Here's a mini testcase.  I've also attached the resulting .s files for
> > -O2 and -O3.
> 
> You do know, don't you, that there are lots of optimizations that GDB
> fails to debug at -O2 and -O3?  If something bad happens at those 
> levels, our practice is to say "turn down the optimization and try again".

Yeah, in general there's no way for GDB to produce the expected
backtrace when the compiler has turned a call in tail position into a
pop-frame-and-jump.  There's simply no record at all of the function
that made the tail call on the stack.

But when there's a tail call to a function with no debug info, it
seems to me that GDB should still do better than just letting the
program run away.  When "step" or "next" notice that they've stepped
into a new function which has no debug info, they're supposed to set a
breakpoint at the return address and run until that's hit.  Now, in
the presence of tail call optimizations, that return address is going
to be one (or more) stack frames further back than you expect, but it
should still get hit eventually.  In your program, that breakpoint
should be set in main, I think.  Doesn't that work?