Single step vs. "tail recursion" optimization

[Donn Terry]

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?

(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.)

Donn


Heres the code:

0x466e37 <regcache_raw_read+151>:       mov    0x1c(%eax),%ecx
0x466e3a <regcache_raw_read+154>:       mov    0x18(%eax),%eax
0x466e3d <regcache_raw_read+157>:       mov    (%eax,%esi,4),%edx
0x466e40 <regcache_raw_read+160>:       mov    0x4(%ebx),%eax
0x466e43 <regcache_raw_read+163>:       add    %eax,%edx
0x466e45 <regcache_raw_read+165>:       mov    (%ecx,%esi,4),%eax
0x466e48 <regcache_raw_read+168>:       mov    %eax,0x10(%ebp)
0x466e4b <regcache_raw_read+171>:       mov    %edx,0xc(%ebp)
0x466e4e <regcache_raw_read+174>:       mov    %edi,0x8(%ebp)
0x466e51 <regcache_raw_read+177>:       lea    0xfffffff4(%ebp),%esp
0x466e54 <regcache_raw_read+180>:       pop    %ebx
0x466e55 <regcache_raw_read+181>:       pop    %esi
0x466e56 <regcache_raw_read+182>:       pop    %edi
0x466e57 <regcache_raw_read+183>:       pop    %ebp
0x466e58 <regcache_raw_read+184>:       jmp    0x77d91e60 <memcpy>
0x466e5d <regcache_raw_read+189>:       lea    0x0(%esi),%esi