From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20524 invoked by alias); 2 Dec 2004 23:13:19 -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 20502 invoked from network); 2 Dec 2004 23:13:15 -0000 Received: from unknown (HELO priv-edtnes46.telusplanet.net) (199.185.220.240) by sourceware.org with SMTP; 2 Dec 2004 23:13:15 -0000 Received: from takamaka.act-europe.fr ([142.179.108.108]) by priv-edtnes46.telusplanet.net (InterMail vM.6.01.03.02 201-2131-111-104-20040324) with ESMTP id <20041202231313.CLRS8345.priv-edtnes46.telusplanet.net@takamaka.act-europe.fr>; Thu, 2 Dec 2004 16:13:13 -0700 Received: by takamaka.act-europe.fr (Postfix, from userid 507) id 359F447DA6; Thu, 2 Dec 2004 15:12:55 -0800 (PST) Date: Thu, 02 Dec 2004 23:13:00 -0000 From: Joel Brobecker To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: [RFC] Infinite backtraces... Message-ID: <20041202231255.GM994@adacore.com> References: <20041202224606.GL994@adacore.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041202224606.GL994@adacore.com> User-Agent: Mutt/1.4i X-SW-Source: 2004-12/txt/msg00052.txt.bz2 > I am not sure I have a sufficiently high-level view of the entire > code that is involved in unwinding, but it seemed to me that we need > to add a new architecture-dependent hook that would tell whether a > given frame is the initial one, and that unwinding can not be done > past this frame. This naturally pointed to a new gdbarch method. > > Something like gdbarch_upper_most_frame_p (....), with a default > value that would always return false. Something I forgot to add was that I thought about adding a frame method (in the frame_unwind struct). But I don't this this is the best approach, as you can have several unwinders active at the same time for the same target, while the end-of-callstack condition would remain the same reguardless of the type of unwinding we're doing. I am sort of walking on thin ice here, though. I could very well imagine a case where we would rely on register value in one case, and a flag from whatever frame information we find in another case. This is why I'm mentioning this idea here. JIC. -- Joel