From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26387 invoked by alias); 10 May 2005 08:39:42 -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 26291 invoked from network); 10 May 2005 08:39:31 -0000 Received: from unknown (HELO andromeda.onevision.de) (212.77.172.62) by sourceware.org with SMTP; 10 May 2005 08:39:31 -0000 Received: from [192.168.5.120] (oppenheim.onevision.de [192.168.5.120]) by andromeda.onevision.de (8.13.1/8.12.9/ROSCH/DDB) with ESMTP id j4A8d2FE016362; Tue, 10 May 2005 10:39:02 +0200 Message-ID: <428072F7.6000600@onevision.de> Date: Tue, 10 May 2005 08:39:00 -0000 From: Roland Schwingel User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 MIME-Version: 1.0 To: Christopher Faylor CC: gdb@sourceware.org Subject: Re: gdb stack trace problems (Addendum) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-05/txt/msg00132.txt.bz2 Hi... gdb-owner@sources.redhat.com wrote on 09.05.2005 01:19:53: > On Sun, May 08, 2005 at 03:30:20PM +0200, Mark Kettenis wrote: > > Date: Mon, 02 May 2005 09:03:08 +0200 > > From: Roland Schwingel > > > > Hi Mark... > > > > Have you already had some time to look into my results with your patch to > > the i386 stack unwinder? At basically it could work but obviously it > > is not advancing to the next stack frame... Attached you will find my > > results > > > >This isn't very encouraging. My approach obviously isn't working very > >well. My suggestion is to go for a Windows-specific solution, where > >one would use a special unwinder for the sort of undebuggable code > >that's found in the Windows system DLLs. But I'm afraid I can't > >really do much since I don't have a Windows system. Chris, is there > >any change you can hack something like this into i386-cygwin-tdep.c? > > What kind of windows-specific solution do you have in mind? How would > you know what to unwind? You could potentially figure out that you're > stuck in a system function but that doesn't mean that you know the > state of the stack. > > If a function doesn't set up a frame pointer and there is no debugging > information available, how would one derive a stack frame? I could > imagine a really complicated "search the stack" technique but I can't > see how it would ever be foolproof. Well... GDB 5.3 was able to dump a correct stack in this case... So it was possible to do in the past. Marks patch for gdb 6.x was not really really bad. It dumped the first stack frame now "somewhat" correctly, but failed to advance to the next stack frame. Maybe we could implement something similar to the gdb 5.3 code but with all the benefits from the 6.x changes? Roland