From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6558 invoked by alias); 15 Jun 2003 18:37:35 -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 6381 invoked from network); 15 Jun 2003 18:37:30 -0000 Received: from unknown (HELO localhost.redhat.com) (24.157.166.107) by sources.redhat.com with SMTP; 15 Jun 2003 18:37:30 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 915AD2B5F; Sun, 15 Jun 2003 14:37:22 -0400 (EDT) Message-ID: <3EECBCE2.90001@redhat.com> Date: Sun, 15 Jun 2003 18:37:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kevin Buettner Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] MIPS: Introduce struct mips_regnums and accessors References: <1030515235130.ZM7492@localhost.localdomain> <3ECBD5C3.3000706@redhat.com> <1030521204035.ZM32420@localhost.localdomain> <3ECD27B0.1060906@redhat.com> <1030522201633.ZM31133@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-06/txt/msg00519.txt.bz2 > I have the following objections to the use of offsets: > > 1) They don't work for floating point registers. (That's assuming > that I can convince you that it's desirable to have 16 cooked > registers for o32...) The reason that it won't work is that, > e.g, an FPA0_OFFSET will need to have different values for the > raw and cooked cases. I think the MIPS has the following: - raw registers These are pretty messed up. register_raw_size, for instance returns a value determined by the ABI. In theory though, this is just a raw buffer. - ABI / debug info registers Currently represented by the virtual registers [sort of]. This is the first view onto the raw registers and is ment to provide something that the ABI / debug info, rather than ISA, expects. For o32 there would be 32 32 bit GPRs and 32 32 bit FPRs. - cli registers This is further layer, providing a view into the above raw (and possibly ABI) registers. These are the $registers that the user manipulates from the CLI. Here, having 64 bit word-swapping o32 FPRs would be useful (but I don't think their usefulness extends back to the ABI - that would result in cross purposes and unnecessary complexity). I get the feeling here that you're trying to fix the third problem, addressing the second as a side effect, while I'm worried about fixing the second (improving the third as a side effect). Re-thinking the problem, and given the above, I think it might be better to provide three register maps: [0 * NUM_REGS .. 1 * NUM_REGS): The raw register buffer. [1 * NUM_REGS .. 2 * NUM_REGS): The ABI registers, mapped onto the raw register set. [2 * NUM_REGS .. 3 * NUM_REGS): The CLI register view, mapped onto RAW (also ABI?) registers. (Perhaps the CLI can steal some of the ABI registers). It should be possible to brute force the second map (I'll try for a patch), and then layer the CLI map onto that and the raw registers. Andrew > 2) The conversion from *_REGNUM is much less transparent. > 3) The use of offsets is more error prone. There's nothing to > prevent you from adding an offset to the wrong boundary start. > 4) The notation is more cumbersome. > > Furthermore, I really don't understand the problem that you had with > my proposed layout. Could you please explain the underlying reasons > for proposing the offset idea? E.g, are you concerned about the > initialization and the maintenance thereof? Or do you just want to > present a minimal view of the raw register numbers to clients outside > of mips-tdep.c? Or something else altogether? > > Kevin >