RE: Single step vs. "tail recursion" optimization

["Donn Terry" <donnte at microsoft dot com>]

No, it doesn't.  In the original case (debugging gdb itself) it was down
a lot
of levels (of debuggable code, just the function being tail-called
wasn't debuggable).
It doesn't work (runs away) in the testcase either.

I haven't tried to figure out what it thinks it is doing under those
circumstances,
being busy putting out other fires.

I understand that you can't expect debugging to work completely as you
expect
in the face of this sort of optimization, but running away has some
potentially
really nasty consequences, so it would be nice to find a way to prevent
that.

I don't have access to implementations other than Inteix at the moment.
Is
this something specific to Interix, to x86's, or is it general?  (I
could easily
imagine any of the above.)  The small testcase I sent the other day
should detect
that easily enough.

Donn

-----Original Message-----
From: Jim Blandy [mailto:jimb@redhat.com] 
Sent: Wednesday, November 13, 2002 9:28 AM
To: Donn Terry
Cc: Michael Snyder; gdb-patches@sources.redhat.com
Subject: Re: Single step vs. "tail recursion" optimization



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?