From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26201 invoked by alias); 8 Nov 2002 01:04:30 -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 26191 invoked from network); 8 Nov 2002 01:04:26 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 8 Nov 2002 01:04:26 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 50A883CF5; Thu, 7 Nov 2002 20:04:27 -0500 (EST) Message-ID: <3DCB0D9B.2010601@redhat.com> Date: Thu, 07 Nov 2002 17:04:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.0) Gecko/20020824 X-Accept-Language: en-us, 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; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-11/txt/msg00211.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? Sounds both new, and, er, painful. GDB would be, er, what would gdb be doing? Lets see. The memcpy() probably doesn't have debug info and hence GDB will try to step over it, just like for a next. This would explain why both step/next give the same behavior. With a next, GDB steps into the first instruction of the function, extracts saved return address, sets a breakpoint on that, and then free runs the target. Perhaphs set a breakpoint on i386_saved_pc_after_call() and see how well it is doing. Can I suggest also trying a tail recursion case where there is debug info for both the caller and the callee? Step and next should behave differently. > (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.) Andrew