From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15006 invoked by alias); 8 May 2005 23:20:27 -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 14906 invoked by uid 22791); 8 May 2005 23:20:13 -0000 Received: from c-66-30-17-189.hsd1.ma.comcast.net (HELO cgf.cx) (66.30.17.189) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Sun, 08 May 2005 23:20:13 +0000 Received: by cgf.cx (Postfix, from userid 201) id ECAAC13C9F2; Sun, 8 May 2005 19:19:53 -0400 (EDT) Date: Sun, 08 May 2005 23:20:00 -0000 From: Christopher Faylor To: roland.schwingel@onevision.de, gdb@sourceware.org Subject: Re: gdb stack trace problems (Addendum) Message-ID: <20050508231953.GG3896@trixie.casa.cgf.cx> Mail-Followup-To: roland.schwingel@onevision.de, gdb@sourceware.org References: <4275D0AC.8000205@onevision.de> <200505081330.j48DUKQc012365@elgar.sibelius.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200505081330.j48DUKQc012365@elgar.sibelius.xs4all.nl> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-05/txt/msg00097.txt.bz2 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. cgf