From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32398 invoked by alias); 17 Mar 2009 15:08:45 -0000 Received: (qmail 32388 invoked by uid 22791); 17 Mar 2009 15:08:43 -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 15:08:37 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id A7AFD2BAAED; Tue, 17 Mar 2009 11:08:35 -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 Eej5Qv3TVZjU; Tue, 17 Mar 2009 11:08:35 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 84FA22BAC21; Tue, 17 Mar 2009 11:08:35 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 31E0CF5CFA; Tue, 17 Mar 2009 08:08:35 -0700 (PDT) Date: Tue, 17 Mar 2009 15:08:00 -0000 From: Joel Brobecker To: Roland Schwingel Cc: gdb Subject: Re: Strange stack trace on Windows Message-ID: <20090317150835.GC32001@adacore.com> References: <49BFAA28.9010400@schwingel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49BFAA28.9010400@schwingel.com> 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/msg00107.txt.bz2 > This list could get quite very long. I already considered to do > something like that, but just as some kind of last resort as the list > could get quite very long. It must contain quite every windows > function. Or completely match dll names like msvcrt.dll Right - this is one of the reasons why AdaCore decided not to go that route. In all fairness, most of our uses debug Ada, and thus do not face the same issue as you do, since they rarely write code that contains calls to Windows functions. So the compromise does not impact us as much as it impacts you. > Wouldn't it be possible to also adjust gdb's stepping code to work with > your patch? Or (also not really nice, but maybe cleaner) to > only use your patch for stack dumping. For stepping rely on the > "other" (means current) frame code. Unfortunately, not. Everything is related: In order to determine whether we stepped into a function during the "next", we do the equivalent of a 2-frame backtrace. However, thinking about this a little more, perhaps there is a way out for the "next" case: Try checking the PC against the start address of the function. If the PC is at the start address of your function, then the function prologue hasn't had time to adjust the stack in such a way that we can't unwind from it, and thus the normal processing should work. > It is quite painful to use gdb on windows for quite a while now. > Windows, whether one may like it or not, is a major platform > and gdb should also operate well here. I am fighting for a long time > with these problems now. As I hinted earlier, I think that this has to do with the fact that you debug code that makes calls to functions that live inside DLLs. This is a relatively specific condition... > Isn't there a general solution thinkable? GDB is cool piece of > software. For me it is "THE" debugger but this problem transforms more > and more into killer problem here. Pedro answered exactly what I would have answered: The real proper way to fix the problem is to teach GDB how to read the Windows "debug" info. So far, no one has had enough interest in this project to see it through. -- Joel