From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29577 invoked by alias); 17 Mar 2009 13:49:15 -0000 Received: (qmail 29564 invoked by uid 22791); 17 Mar 2009 13:49:14 -0000 X-SWARE-Spam-Status: No, hits=-2.5 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 13:49:09 +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 n2HDmOoP031315; Tue, 17 Mar 2009 14:48:24 +0100 Message-ID: <49BFAA28.9010400@schwingel.com> Date: Tue, 17 Mar 2009 13:49: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 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/msg00104.txt.bz2 Hi Joel... Thanks for your reply.... gdb-owner@sourceware.org wrote on 17.03.2009 14:19:49: > > 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 :) It is of very good use. If I only could get the stepping now right... ;-) > > 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. Yes... :-) This is true... I already observed this... It has disappeared. > 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. 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 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. 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. 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. > PS: It looks like I'll have to implement the same type of patch for > x86_64-windows. Might be useful, too... At least for me.... ;-) Roland