From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28373 invoked by alias); 6 Dec 2004 03:51:20 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 28331 invoked from network); 6 Dec 2004 03:51:15 -0000 Received: from unknown (HELO arwen.tausq.org) (64.81.244.109) by sourceware.org with SMTP; 6 Dec 2004 03:51:15 -0000 Received: by arwen.tausq.org (Postfix, from userid 1000) id 63EC2111F48; Sun, 5 Dec 2004 19:51:12 -0800 (PST) Date: Mon, 06 Dec 2004 04:15:00 -0000 From: Randolph Chung To: Joel Brobecker Cc: gdb-patches@sources.redhat.com Subject: Re: [RFC] Infinite backtraces... Message-ID: <20041206035112.GE6359@tausq.org> Reply-To: Randolph Chung References: <20041202231255.GM994@adacore.com> <20041203024314.GR6359@tausq.org> <20041203025737.GT994@adacore.com> <20041203045252.GU6359@tausq.org> <20041203165430.GC16491@adacore.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041203165430.GC16491@adacore.com> X-GPG: for GPG key, see http://www.tausq.org/gpg.txt User-Agent: Mutt/1.5.6+20040722i X-SW-Source: 2004-12/txt/msg00152.txt.bz2 > I'll give it a try and see if we can skip them. I like the idea of > having a switch to hide them, though. That would be very nice. but > then we need to add a new type of frames. As far as I can tell > (understand: from code inspection), the stub frames are marked as > NORMAL_FRAMEs. > > > see: > > http://sources.redhat.com/ml/gdb-patches/2004-05/msg00741.html > > Thanks muchly for the pointer. I missed that thread. i just found another instance where these stub frames is causing problems, and this one is not just "cosmetic" ... suppose you are calling a function through a stub, so your stack frames are: #0 callee #1 callee stub #2 caller if you do a "finish" from callee, gdb will stop in the callee stub instead of at the caller. quite annoying :( i'm wondering if we should make the hppa unwinders more export-stub aware -- e.g. in hppa_frame_cache (), after we've determined the address of the current frame, we can see if this is an "export stub" frame, and if so automatically rewind one more frame. i think this should work and shouldn't cause any problems.... thoughts? randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/