From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16572 invoked by alias); 23 Oct 2002 15:21:32 -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 16558 invoked from network); 23 Oct 2002 15:21:31 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 23 Oct 2002 15:21:31 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 184OFm-0006tb-00 for ; Wed, 23 Oct 2002 11:21:06 -0500 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 184NKT-0002b1-00 for ; Wed, 23 Oct 2002 11:21:53 -0400 Date: Wed, 23 Oct 2002 08:21:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Subject: Re: [patch/rfc] Add frame_read_signed/unsigned_register(); convert h8300 to print_registers_info() Message-ID: <20021023152153.GA9628@nevyn.them.org> Mail-Followup-To: gdb-patches@sources.redhat.com References: <3DB610B9.5040906@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DB610B9.5040906@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-10/txt/msg00461.txt.bz2 On Tue, Oct 22, 2002 at 11:00:09PM -0400, Andrew Cagney wrote: > Hmm, > > (I think I might split this in two) Looks like a good idea. > > The attached adds the methods: > > +extern void frame_read_signed_register (struct frame_info *frame, > + int regnum, LONGEST *val); > +extern void frame_read_unsigned_register (struct frame_info *frame, > + int regnum, ULONGEST *val); > > These correspond to the frame_unwind_XXXX methods() except that they > return the value of a register in THIS frame rather than the value of > the register in the PREVIOUS frame. > > They are simply convenience functions to make it easier to obtain a > specified frame's register value. > > Thoughts? I think it's a great idea. One thought... > 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. That means the register which would be in the hardware registers if this frame were current, right? Should we allow NULL to imply the current frame? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer