From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25248 invoked by alias); 16 Oct 2007 22:04:31 -0000 Received: (qmail 25216 invoked by uid 22791); 16 Oct 2007 22:04:12 -0000 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO brahms.sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 16 Oct 2007 22:04:06 +0000 Received: from brahms.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by brahms.sibelius.xs4all.nl (8.14.1/8.14.0) with ESMTP id l9GM14PG000594; Wed, 17 Oct 2007 00:01:04 +0200 (CEST) Received: (from kettenis@localhost) by brahms.sibelius.xs4all.nl (8.14.1/8.14.1/Submit) id l9GM13MR006755; Wed, 17 Oct 2007 00:01:03 +0200 (CEST) Date: Tue, 16 Oct 2007 22:09:00 -0000 Message-Id: <200710162201.l9GM13MR006755@brahms.sibelius.xs4all.nl> From: Mark Kettenis To: brobecker@adacore.com CC: gdb-patches@sourceware.org, jimb@codesourcery.com In-reply-to: <20071012035336.GA4038@adacore.com> (message from Joel Brobecker on Thu, 11 Oct 2007 20:53:36 -0700) Subject: Re: [rfc] Unwind the ARM CPSR References: <20071011145137.GA18336@caradoc.them.org> <20071012035336.GA4038@adacore.com> 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/msg00430.txt.bz2 > Date: Thu, 11 Oct 2007 20:53:36 -0700 > From: Joel Brobecker > > > 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. And risking infinite recursion? I'm fairly sure it is a mistake to call frame_register(CURRENT) at this place. > 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 wouldn't be so sure. Andrew Cagney put quite a bit of thought in the interface, and while it sometimes appears to be strange on first sight, it has always proven to be the right choice. > 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) I agree it is a mental excercise, but it prevents you from doing stupid things. > > 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. I think it is a very bad idea. It will take ages before all targets are converted, and having two functions to do the same thing will be even more confusing.