From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4580 invoked by alias); 7 Nov 2002 19:18:35 -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 4564 invoked from network); 7 Nov 2002 19:18:33 -0000 Received: from unknown (HELO mail2.microsoft.com) (131.107.3.124) by sources.redhat.com with SMTP; 7 Nov 2002 19:18:33 -0000 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 7 Nov 2002 11:17:44 -0800 Received: from 157.54.8.155 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 07 Nov 2002 11:17:44 -0800 Received: from red-msg-08.redmond.corp.microsoft.com ([157.54.12.5]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 7 Nov 2002 11:17:43 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Single step vs. "tail recursion" optimization Date: Thu, 07 Nov 2002 11:18:00 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "Donn Terry" To: X-OriginalArrivalTime: 07 Nov 2002 19:17:43.0951 (UTC) FILETIME=[5930C1F0:01C28692] X-SW-Source: 2002-11/txt/msg00184.txt.bz2 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 : 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