From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28647 invoked by alias); 17 Mar 2009 13:19:58 -0000 Received: (qmail 28638 invoked by uid 22791); 17 Mar 2009 13:19:57 -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 13:19:52 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 472532BABEB; Tue, 17 Mar 2009 09:19:50 -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 mBmz1HZ34U7P; Tue, 17 Mar 2009 09:19:50 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 30C0C2BABE9; Tue, 17 Mar 2009 09:19:50 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id A414CF5C40; Tue, 17 Mar 2009 06:19:49 -0700 (PDT) Date: Tue, 17 Mar 2009 13:19:00 -0000 From: Joel Brobecker To: Roland Schwingel Cc: gdb Subject: Re: Strange stack trace on Windows Message-ID: <20090317131949.GA32001@adacore.com> References: <49BF903D.6090900@onevision.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49BF903D.6090900@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/msg00103.txt.bz2 > With the patch from Joel I get really good strack traces back in this case. Glad to hear that you were able to put the patch to good use :) > But there is mabye a sideeffect of this patch when stepping thru an > application. [...] > As soon as I type next on one of the setbuf() functions gdb steps > directly to the assembly code of setbuf not over it as I would like to > have it... I suspect that this is because we fail to detect that the caller of setbuf if "function", most likely because the setbuf function does not setup a frame. You can confirm this by requesting a backtrace after you landed inside "setbuf". If your "function" has disappeared from the backtrace, you know. As I explained back then, this patch is a compromise: You'll win some, and lose some. But you can change a bit the compromise by deciding that certain routines should be excluded from the heuristics. For instance, you can expand i386_in_dll to not only check whether the PC is inside a DLL, but also check the name of the function associated to that PC. One possibility is to only match the name of the routines you know are causing trouble. Another way it to exclude all frameless routines that you know GDB can actually unwind from. At AdaCore, we decided to stay away from that, because it's very hacky and OS version dependent. PS: It looks like I'll have to implement the same type of patch for x86_64-windows. -- Joel