From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16336 invoked by alias); 12 Oct 2007 03:54:18 -0000 Received: (qmail 16328 invoked by uid 22791); 12 Oct 2007 03:54:18 -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, 12 Oct 2007 03:54:16 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 98EF92AB392; Thu, 11 Oct 2007 23:53:39 -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 nQ7L8BMAoRfw; Thu, 11 Oct 2007 23:53:39 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 5F05D2ACCE6; Thu, 11 Oct 2007 23:53:39 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 06478E7B58; Thu, 11 Oct 2007 20:53:37 -0700 (PDT) Date: Fri, 12 Oct 2007 08:08:00 -0000 From: Joel Brobecker To: gdb-patches@sourceware.org, Mark Kettenis , Jim Blandy Subject: Re: [rfc] Unwind the ARM CPSR Message-ID: <20071012035336.GA4038@adacore.com> References: <20071011145137.GA18336@caradoc.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071011145137.GA18336@caradoc.them.org> User-Agent: Mutt/1.4.2.2i Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-10/txt/msg00332.txt.bz2 > So why shouldn't the argument be the CURRENT (i.e. THIS) frame > instead? Then we can call frame_register (CURRENT) instead of > frame_unwind_register (NEXT) to get the same result, plus we'll > have the option of calling frame_unwind_register (CURRENT) when > we need it. I can see why you'd like some feedback. This (amazing piece of) code has always been a bit difficult for me to grasp in its entirety... I hope others will take some time to think about it too, because I don't feel sufficiently proficient to provide a confident answer. FWIW, I don't see how we could end up breaking something with your approach. As it turns out, there is a comment that says about the prev_register method: Why not pass in THIS_FRAME? By passing in NEXT frame and THIS cache, the supplied parameters are consistent with the sibling function THIS_ID. So it sounds like the author wasn't seeing any issue with that either. I personally think that passing the current frame will make this function a little easier to understand too, no? (I find the twist of computing the caller's registers of this frame using the next frame a constant mental exercise) > Of course this would be a pain to change all at once since there are > so many unwinders. I'd introduce a new method instead > (unwind->prev_register_this?). What do you think? Sounds like a possible plan to me. -- Joel