From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27967 invoked by alias); 16 May 2008 16:02:30 -0000 Received: (qmail 27946 invoked by uid 22791); 16 May 2008 16:02:28 -0000 X-Spam-Check-By: sourceware.org Received: from qnxmail.qnx.com (HELO nimbus.ott.qnx.com) (209.226.137.76) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 16 May 2008 16:02:11 +0000 Received: from [10.42.100.129] (dhcp-100-129.ott.qnx.com [10.42.100.129]) by nimbus.ott.qnx.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id K6WT330B; Fri, 16 May 2008 12:02:08 -0400 Message-ID: <482DB015.2020801@qnx.com> Date: Fri, 16 May 2008 16:02:00 -0000 From: Aleksandar Ristovski User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Daniel Jacobowitz CC: gdb@sourceware.org Subject: Re: Frame lost after 'leave' and before 'ret' instruction on i386? References: <482DA814.7030703@qnx.com> <20080516155828.GA31038@caradoc.them.org> In-Reply-To: <20080516155828.GA31038@caradoc.them.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-05/txt/msg00126.txt.bz2 Daniel Jacobowitz wrote: > On Fri, May 16, 2008 at 11:28:20AM -0400, Aleksandar Ristovski wrote: >> What happens is, we have restored the stack pointer but gdb is unaware of that fact and tries to unwind using already unwound value... >> >> how is this supposed to work? > > Poorly. > > The biggest problem, in my opinion, is that GCC emits bogus unwind > info that does not describe epilogues. I don't know about other > compilers. So far no one has fixed this in a way that didn't bloat > debug info to an unacceptable size. > > When DWARF unwinding is not in use, there's the in_epilogue_p hook. > Prologue analyzers could also detect epilogues using the same > technique. But this is slow and complicated. > assuming the problem occurs only while single stepping, couldn't we look for 'ret' 'leave' and such and 'figure out' that stack has changed and are now stepping through still the same function but with previous frame?