Re: Single step vs. "tail recursion" optimization

[Andrew Cagney <ac131313 at redhat dot com>]

> While debugging gdb, I ran across a really nasty little issue: the gcc
> guys (for the "bleeding edge", at least) have generated an optimization
> such that if the last thing in function x is a function call to y, it
> will short circut the return from x, and set things up so it returns
> directly from y.  (A special case of tail recursion optimizations.)
>
> If you try to n (or s) over that, the debugged program runs away because
> gdb doesn't know about that magic.  The real example is
> regcache_raw_read, which ends in a memcpy.  Instead of jsr-ing to the
> memcpy and then returning, it fiddles with the stack and jmps to memcpy.
> Is this a known issue, and is it being worked, or have I just run across
> something
> new to worry about?
Sounds both new, and, er, painful.  GDB would be, er, what would gdb be 
doing?

Lets see.

The memcpy() probably doesn't have debug info and hence GDB will try to 
step over it, just like for a next.  This would explain why both 
step/next give the same behavior.

With a next, GDB steps into the first instruction of the function, 
extracts saved return address, sets a breakpoint on that, and then free 
runs the target.  Perhaphs set a breakpoint on 
i386_saved_pc_after_call() and see how well it is doing.

Can I suggest also trying a tail recursion case where there is debug 
info for both the caller and the callee?  Step and next should behave 
differently.

> (This is on Interix (x86, obviously from the code below) with a gcc
> that's less than
> a week old.  I have no idea how long it might actually have been this
> way.  I doubt
> the problem is actually unique to the x86 as this is a very general
> optimization.)
Andrew