From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23124 invoked by alias); 23 Oct 2002 16:50:54 -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 23117 invoked from network); 23 Oct 2002 16:50:53 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 23 Oct 2002 16:50:53 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 184PeF-00072A-00; Wed, 23 Oct 2002 12:50:27 -0500 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 184Oiw-0003VJ-00; Wed, 23 Oct 2002 12:51:14 -0400 Date: Wed, 23 Oct 2002 09:50:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: NULL selected/current frame; Was: [patch/rfc] Add frame_read_signed/unsigned_register(); convert h8300 to print_registers_info() Message-ID: <20021023165114.GA13352@nevyn.them.org> Mail-Followup-To: Andrew Cagney , gdb-patches@sources.redhat.com References: <3DB610B9.5040906@redhat.com> <20021023152153.GA9628@nevyn.them.org> <3DB6D2BD.3040708@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DB6D2BD.3040708@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-10/txt/msg00463.txt.bz2 On Wed, Oct 23, 2002 at 12:47:57PM -0400, Andrew Cagney wrote: > > >> void > >>+frame_read_unsigned_register (struct frame_info *frame, int regnum, > >>+ ULONGEST *val) > >>+{ > >>+ frame_unwind_unsigned_register (get_next_frame (frame), regnum, val); > >>+} > > > > > >So, the register belonging to this frame. > > Yes. The old roughly equivalent function was get_saved_register. > > >That means the register > >which would be in the hardware registers if this frame were current, > >right? > > To be pedantic, no. A frame's registers are ALWAYS found by unwinding > get_next_frame(FRAME). It just so happens that registers unwound from > get_next_frame(current_frame) come from the register cache. > > The difference is subtle but important. current_frame isn't the special > case, get_next_frame(current_frame) is. Unfortunatly much of the GDB > code treated ``current_frame'' as special creating unnecessary > complexity and ongoing confusion. Per generic_unwind_get_saved_register(): > > /* Reached the the bottom (youngest, inner most) of the frame chain > (youngest, inner most) frame, go direct to the hardware register > cache (do not pass go, do not try to cache the value, ...). The > unwound value would have been cached in frame->next but that > doesn't exist. This doesn't matter as the hardware register > cache is stopping any unnecessary accesses to the target. */ > > /* NOTE: cagney/2002-04-14: It would be nice if, instead of a > special case, there was always an inner frame dedicated to the > hardware registers. Unfortunatly, there is too much unwind code > around that looks up/down the frame chain while making the > assumption that each frame level is using the same unwind code. */ > > >Should we allow NULL to imply the current frame? > > Definitly no :-) > > There is a bit of dogma here - there is always a frame. The above > should not be called with NULL. Code that calls this checks that > selected_frame != NULL. I'll add a ``gdb_assert (frame != NULL)'' and a > comment to that effect. > > As for get_next_frame(FRAME), if that returns NULL, we've fallen off the > inner most frame and should get the register value from the register > cache. (Oh, while get_next_frame(current_frame) will always return > NULL, there may come a time when current_frame->next does not :-). OK, I see where you're going, vis some of the comments about a "frame" for the hardware registers. I can buy that. I like these new functions... -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer