Re: Single step vs. "tail recursion" optimization

[Michael Snyder <msnyder@redhat.com>]

Donn Terry wrote:
> 
> 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

Tail-recursion isn't a new optimization, but I have almost no
(only the vaguest) recollection of ever having run up against 
it before.  Could be there's a change with the way GCC is 
implementing it.  Could be we never handled it before.

This sounds like a good argument for parsing the epilogue...   ;-(

Michael

> 
> 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