From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14708 invoked by alias); 21 May 2003 20:40:44 -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 14686 invoked from network); 21 May 2003 20:40:43 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 21 May 2003 20:40:43 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h4LKehH18217 for ; Wed, 21 May 2003 16:40:43 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h4LKegI29617; Wed, 21 May 2003 16:40:42 -0400 Received: from localhost.localdomain (vpn50-3.rdu.redhat.com [172.16.50.3]) by pobox.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h4LKefo11599; Wed, 21 May 2003 16:40:41 -0400 Received: (from kev@localhost) by localhost.localdomain (8.11.6/8.11.6) id h4LKeZx32421; Wed, 21 May 2003 13:40:35 -0700 Date: Wed, 21 May 2003 20:40:00 -0000 From: Kevin Buettner Message-Id: <1030521204035.ZM32420@localhost.localdomain> In-Reply-To: Andrew Cagney "Re: [RFA] MIPS: Introduce struct mips_regnums and accessors" (May 21, 3:38pm) References: <1030515235130.ZM7492@localhost.localdomain> <3ECBD5C3.3000706@redhat.com> To: Andrew Cagney , Kevin Buettner Subject: Re: [RFA] MIPS: Introduce struct mips_regnums and accessors Cc: gdb-patches@sources.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-05/txt/msg00401.txt.bz2 On May 21, 3:38pm, Andrew Cagney wrote: > I think the struct contains too many redudnant fields. Redundant? In what way? > Instead it can > be be trimmed back to identify just the boundaries between the different > register groups vis: > > - gp0 (gp31?) > - fp0 > - hi, lo > - pc > - various status registers > - others? With the exception of fplast (which I added), the member names are identical to the macro names used in tm-mips.h. I did this to make it easier to convert *_REGNUM to using the struct members. > As for assigning meaning to specific registers (v0, a0, ...) within a > group, offsets can be used vis: > > v0_regnum (regnums) === regnums->gp0 + offset; This makes it much more difficult to do an obvious conversion from (e.g.) V0_REGNUM to rawnums->v0_regnum. Also, do you really think it's preferable to have to say: regnums->gp0 + regnumoffsets->v0_offset instead of regnums->v0_regnum ? I like the last one better due to it's being more concise. The initialization may be a little bit harder, but using them will be easier and more error free. E.g, with the style you advocate, it's possible to say ``regnums->fp0 + regnumoffsets->v0_offset'', but that was very likely an error on the part of the author. Anyway, I am firmly against the offset idea. I _do_ think, however, it would be useful to have gp0_regnum and gplast_regnum members at some point. I considered adding them, but decided against it on the grounds that the first step to converting from _REGNUM to rawnums->_regnum should be as obvious and straightforward as possible. > With regard to having only 16 o32 FP registers, is that right? I think so, yes. I've been told that for o32 you only really have 16 FP registers. > Does it just confuse things? Doesn't the o32 debug info assume a bank of 32 > contigious 32 bit registers? As I understand it, the odd register numbers are never used. I have the {stab,ecoff,dwarf,dwarf2}_reg_to_regnum functions convert to the appropriate cooked numbers. I think things will end up being much more confused if you somehow throw the odd registers into the mix. Consider iterating over the set of cooked floating point registers. If we throw the odd numbered registers in somehow, we'll have to arrange to skip them in most circumstances. Also, if we do throw in the odd registers, what should their types be? > A location expression for a double in > ``f0'' would be f0:f1 for instance. I don't think that's the representation. I.e, you only see the f0, not the f1. I can arrange for a warning or error for odd registers if you like. > > +/* MIPS register numbers. */ > > +struct mips_regnums > > + { > > + int zero_regnum; /* The zero register; read-only, always 0. */ > > + int v0_regnum; /* Function return value. */ > > + int a0_regnum; /* First GPR used for passing arguments. */ > > + int t9_regnum; /* Contains address of callee in PIC code. */ > > + int sp_regnum; /* Stack pointer. */ > > + int ra_regnum; /* Return address. */ > > + int ps_regnum; /* Processor status. */ > > + int hi_regnum; /* High portion of internal multiply/divide > > + register. */ > > + int lo_regnum; /* Low portion of internal multiply/divide > > + register. */ > > + int badvaddr_regnum; /* Address associated with > > + addressing exception. */ > > + int cause_regnum; /* Describes last exception. */ > > + int pc_regnum; /* Program counter. */ > > + int fcrcs_regnum; /* FP control/status. */ > > + int fcrir_regnum; /* FP implementation/revision. */ > > + int fp0_regnum; /* First floating point register. */ > > + int fplast_regnum; /* Last floating point register. */ > > + int fpa0_regnum; /* First floating point register used for > > + passing floating point arguments. */ > > + int first_embed_regnum; /* First CP0 register for embedded use. */ > > + int last_embed_regnum; /* Last CP0 register for embedded use. */ > > + int prid_regnum; /* Processor ID. */ > > + > > + int last_arg_regnum; /* Last general purpose register used for > > + passing arguments. (a0_regnum is the > > + first.) */ > > + int last_fp_arg_regnum; /* Last floating point register used for > > + passing floating point arguments. */ > > + };