From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13751 invoked by alias); 8 Nov 2002 19:43:09 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 13709 invoked from network); 8 Nov 2002 19:43:08 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 8 Nov 2002 19:43:08 -0000 Received: from int-mx2.corp.redhat.com (nat-pool-rdu-dmz.redhat.com [172.16.52.200]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id gA8JKJw04569 for ; Fri, 8 Nov 2002 14:20:19 -0500 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id gA8Jh6l25700; Fri, 8 Nov 2002 14:43:06 -0500 Received: from redhat.com (reddwarf.sfbay.redhat.com [172.16.24.50]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id gA8Jh5D08562; Fri, 8 Nov 2002 11:43:05 -0800 Message-ID: <3DCC13C9.E7B94D50@redhat.com> Date: Fri, 08 Nov 2002 11:43:00 -0000 From: Michael Snyder Organization: Red Hat, Inc. X-Accept-Language: en MIME-Version: 1.0 To: Donn Terry CC: gdb-patches@sources.redhat.com Subject: Re: Single step vs. "tail recursion" optimization References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-11/txt/msg00234.txt.bz2 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 : mov 0x1c(%eax),%ecx > 0x466e3a : mov 0x18(%eax),%eax > 0x466e3d : mov (%eax,%esi,4),%edx > 0x466e40 : mov 0x4(%ebx),%eax > 0x466e43 : add %eax,%edx > 0x466e45 : mov (%ecx,%esi,4),%eax > 0x466e48 : mov %eax,0x10(%ebp) > 0x466e4b : mov %edx,0xc(%ebp) > 0x466e4e : mov %edi,0x8(%ebp) > 0x466e51 : lea 0xfffffff4(%ebp),%esp > 0x466e54 : pop %ebx > 0x466e55 : pop %esi > 0x466e56 : pop %edi > 0x466e57 : pop %ebp > 0x466e58 : jmp 0x77d91e60 > 0x466e5d : lea 0x0(%esi),%esi