From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16339 invoked by alias); 9 May 2005 04:48:39 -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 16324 invoked by uid 22791); 9 May 2005 04:48:33 -0000 Received: from legolas.inter.net.il (HELO legolas.inter.net.il) (192.114.186.24) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Mon, 09 May 2005 04:48:33 +0000 Received: from zaretski (IGLD-83-130-243-144.inter.net.il [83.130.243.144]) by legolas.inter.net.il (MOS 3.5.6-GR) with ESMTP id EIC04071 (AUTH halo1); Mon, 9 May 2005 07:47:40 +0300 (IDT) Date: Mon, 09 May 2005 04:48:00 -0000 From: "Eli Zaretskii" To: roland.schwingel@onevision.de, gdb@sourceware.org Message-ID: <01c55452$Blat.v2.4$03d6fe00@zahav.net.il> Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=ISO-8859-1 In-reply-to: <20050508231953.GG3896@trixie.casa.cgf.cx> (message from Christopher Faylor on Sun, 8 May 2005 19:19:53 -0400) Subject: Re: gdb stack trace problems (Addendum) Reply-to: Eli Zaretskii References: <4275D0AC.8000205@onevision.de> <200505081330.j48DUKQc012365@elgar.sibelius.xs4all.nl> <20050508231953.GG3896@trixie.casa.cgf.cx> X-SW-Source: 2005-05/txt/msg00100.txt.bz2 > Date: Sun, 8 May 2005 19:19:53 -0400 > From: Christopher Faylor > > 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. Does the MSVC debugger manage to display a sensible backtrace in this case? If it does not, we don't need to worry, I think. If it does, then perhaps teh frameless functions in system DLLs follow some pattern in their prologue that could help us? Or perhaps they save stack-related info in some Windows-specific place? Just my $0.02.