From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8900 invoked by alias); 17 Mar 2009 15:39:13 -0000 Received: (qmail 8880 invoked by uid 22791); 17 Mar 2009 15:39:10 -0000 X-SWARE-Spam-Status: No, hits=1.9 required=5.0 tests=AWL,BAYES_00,BOTNET,RDNS_NONE X-Spam-Check-By: sourceware.org Received: from Unknown (HELO andromeda.onevision.de) (212.77.172.62) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 17 Mar 2009 15:39:06 +0000 Received: from [192.168.5.120] (kgi05104.onevision.de [192.168.5.120]) by andromeda.onevision.de (8.14.2/8.12.9/ROSCH/DDB) with ESMTP id n2HFch9C016547; Tue, 17 Mar 2009 16:38:43 +0100 Message-ID: <49BFC403.3070306@onevision.de> Date: Tue, 17 Mar 2009 15:39:00 -0000 From: Roland Schwingel User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Joel Brobecker , gdb Subject: Re: Strange stack trace on Windows Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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/msg00110.txt.bz2 Hi... Joel Brobecker wrote on 17.03.2009 16:08:35: > > 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. 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). > > 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... Really so specific? I don't think so. Having dlls is quite common on windows. The operating system itself is mostly a bunch of dlls. And if one wants to use these functions he has to call them. As in my example setbuf() from msvcrt.dll. > > 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. 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. Roland