From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8689 invoked by alias); 18 Mar 2009 09:26:26 -0000 Received: (qmail 8190 invoked by uid 22791); 18 Mar 2009 09:26:25 -0000 X-SWARE-Spam-Status: No, hits=2.0 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; Wed, 18 Mar 2009 09:26:20 +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 n2I9PurQ015254; Wed, 18 Mar 2009 10:25:56 +0100 Message-ID: <49C0BE1F.8050909@onevision.de> Date: Wed, 18 Mar 2009 09:26: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/msg00115.txt.bz2 Hi Joel, Joel Brobecker wrote on 17.03.2009 20:42:56: > > 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. First thank you for your patch and time! I really appreciate that! I adapted your diff (hopefully correctly) to match the i386_frame_cache() function from gdb's CVS head. Obviously is your i386-tdep.c quite different to the one from CVS head. I think I did not made any mistake in adding the comparison. Unfortunately it does not work. cache->pc is set from get_frame_func(this_frame). current_pc is set from get_frame_pc(this_frame) (BTW: In the current CVS head there is no current_pc anymore in i386_frame_cache(). I added it on my own.) In my tests both cache->pc and current_pc are ALWAYS identical. Mabye it has something to do with your different i386-tdep.c? Would it help when I create sample code and send it to you? Again thank you for patch, Roland