This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: Single step vs. "tail recursion" optimization
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