From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21691 invoked by alias); 17 Mar 2009 19:43:05 -0000 Received: (qmail 21674 invoked by uid 22791); 17 Mar 2009 19:43:03 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 17 Mar 2009 19:42:59 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 7B45B2BABC3; Tue, 17 Mar 2009 15:42:57 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 5giF6dlOnRCA; Tue, 17 Mar 2009 15:42:57 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 61DEF2BABC2; Tue, 17 Mar 2009 15:42:57 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id C2673F5CFA; Tue, 17 Mar 2009 12:42:56 -0700 (PDT) Date: Tue, 17 Mar 2009 19:43:00 -0000 From: Joel Brobecker To: Roland Schwingel Cc: gdb Subject: Re: Strange stack trace on Windows Message-ID: <20090317194256.GH32001@adacore.com> References: <49BFC403.3070306@onevision.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="4Ckj6UjgE2iN1+kY" Content-Disposition: inline In-Reply-To: <49BFC403.3070306@onevision.de> User-Agent: Mutt/1.5.18 (2008-05-17) 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: 2009-03/txt/msg00112.txt.bz2 --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-length: 980 > That sounds interesting... :-) > Could you outline that a bit more? Where and how can I do that? > (I am digging in gdb's source only for a few days now). You can try the attached patch. What it does is that it matches the "current_pc" with the start address of the associated function (if any). If they are identical, then we're at the beginning of the function. In that case, we know that the function will appear frameless since the frame hasn't been setup, but we also know how to unwind properly from it. I can't test the patch right now, so let me know how it goes. > Hmm.. Are so few people using gdb on windows? I think there should be > way more interest in getting gdb to deal right with MS debugging > format in order to get also debugging with frameless functions right. Not sure. I suspect that most people don't debug programs using threads, and so don't need AdaCore's patch. And if you don't install the patch, then the "next" problem goes away. -- Joel --4Ckj6UjgE2iN1+kY Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="unwind.diff" Content-length: 546 diff --git a/gdb/i386-tdep.c b/gdb/i386-tdep.c index 0d77fab..073721e 100644 --- a/gdb/i386-tdep.c +++ b/gdb/i386-tdep.c @@ -1561,7 +1561,8 @@ i386_frame_cache (struct frame_info *this_frame, void **this_cache) functions this might work too. */ current_pc = get_frame_pc (this_frame); - if (i386_in_dll (current_pc) + if (current_pc == cache->pc + && i386_in_dll (current_pc) && !i386_function_has_frame (current_pc)) { /* Functions in DLL for which do not seem to create a standard --4Ckj6UjgE2iN1+kY--