From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16170 invoked by alias); 22 Jul 2004 15:17:03 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 16161 invoked from network); 22 Jul 2004 15:17:02 -0000 Received: from unknown (HELO takamaka.act-europe.fr) (142.179.108.108) by sourceware.org with SMTP; 22 Jul 2004 15:17:02 -0000 Received: by takamaka.act-europe.fr (Postfix, from userid 507) id 996D747D91; Thu, 22 Jul 2004 08:17:01 -0700 (PDT) Date: Thu, 22 Jul 2004 18:28:00 -0000 From: Joel Brobecker To: Michael Elizabeth Chastain Cc: eliz@gnu.org, kettenis@chello.nl, cagney@gnu.org, gdb@sources.redhat.com Subject: Re: [6.2] PROBLEMS file Message-ID: <20040722151701.GA20596@gnat.com> References: <20040722093553.624FF4B104@berman.michael-chastain.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040722093553.624FF4B104@berman.michael-chastain.com> User-Agent: Mutt/1.4i X-SW-Source: 2004-07/txt/msg00282.txt.bz2 > Mark Kettenis writes: > > There will always be cases where GDB will get confused and lose track. > > In that case it will possibly provide an endless or very long backtrace > > containing garbage. > > I'm okay with this part, as long as the user can easily get it > out of it at the "press space to continue" prompt. We saw the same sort of issues on Windows as well, trying to unwind from functions in the ntdll DLL. Unfortunately in that case, we don't get an infinite backtrace, we get a backtrace that doesn't provide the part that the user is probably looking for (the part refering to his code, before the call to the ntdll services). Something like this: #0 0x7ffe0304 in ?? () #1 0x77f7f4af in ntdll!ZwWaitForSingleObject () from ntdll.dll #2 0x77e7788b in WaitForSingleObjectEx () from /WINDOWS/system32/KERNEL32.DLL #3 0x00000778 in ?? () #4 0x00000000 in ?? () from #5 0x010df2c8 in ?? () #6 0x000003e8 in ?? () [snip] #27 0x77e79d6a in WaitForSingleObject () from /WINDOWS/system32/KERNEL32.DLL #28 0x00000778 in ?? () #29 0x000003e8 in ?? () #30 0x00000000 in ?? () from #31 0x61074971 in siginterrupt () from /bin/cygwin1.dll Previous frame inner to this frame (corrupt stack?) In the backtrace above, only frame 0 to 2 are correct. After that, GDB goes in limbo until it finally finds out that something is wrong. The backtrace doesn't show how you got there, and I can imagine that it could be fustrating for a user. I have been working on and off on a small patch that would allow the user to tell GDB to trust %ebp instead of trying to read the prologue and guess the location of the return address for frameless functions. The idea would be to offer this alternative when the current unwinder fails. I have a pretty simple minded patch that seems to be more or less working, but I still have ~200 regressions compared to the current unwinder. I would like to have a look at them, and if possible fix them, before I submit what I have for review. -- Joel