From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4260 invoked by alias); 19 Oct 2007 04:30:00 -0000 Received: (qmail 4250 invoked by uid 22791); 19 Oct 2007 04:29:59 -0000 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 19 Oct 2007 04:29:56 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 80E282AB222; Fri, 19 Oct 2007 00:29:54 -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 f9ahyGM8C5CO; Fri, 19 Oct 2007 00:29:54 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id D9CAC2AB221; Fri, 19 Oct 2007 00:29:53 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 69EB7E7AC8; Thu, 18 Oct 2007 21:29:51 -0700 (PDT) Date: Fri, 19 Oct 2007 04:30:00 -0000 From: Joel Brobecker To: gdb@sourceware.org, Mark Kettenis Subject: Re: [RFC] Using values to handle unwinding Message-ID: <20071019042951.GA6168@adacore.com> References: <20071017160350.GA26804@caradoc.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071017160350.GA26804@caradoc.them.org> User-Agent: Mutt/1.4.2.2i 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: 2007-10/txt/msg00163.txt.bz2 > - Uses GDB's value infrastructure. Values carry around the > location information which previously took four extra arguments > to every unwinder. And this lets us use our existing value > manipulation routines as necessary. I really like this part. It looks very elegant to me. > - Simplifies getting other registers from the PREV frame. This idea was under discussion on gdb-patches. I said it looked like a good idea, but Mark expressed some concerns (to which I think you tried to answer). > This patch leaves the existing prev_register method. If we want to > adopt this new approach then I would recommend not doing that at all: > just change the type of the prev_register field, break all targets > until they are updated, and fix them. We can do it on a branch and > merge the whole branch at once, or do it quickly in HEAD. Converting > the DWARF-2 reader took me only an hour or two, which included writing > the helper routines. I don't mind breaking all the targets if this is the way we want to do it. But either way, whether we use a branch or not, I'd like us to break the target by breaking the build. This way, managing to build again means we're done with the conversion. If I understand the patch correctly, this is going to be the case, right? You're removing some old routines, and replacing with a new one that has a different name. -- Joel