From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3450 invoked by alias); 21 May 2003 18:07:02 -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 3345 invoked from network); 21 May 2003 18:07:01 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.131) by sources.redhat.com with SMTP; 21 May 2003 18:07:01 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id E410C2B2F; Wed, 21 May 2003 14:06:49 -0400 (EDT) Message-ID: <3ECBC039.7040502@redhat.com> Date: Wed, 21 May 2003 18:07: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: MIPS_LAST_FP_ARG_REGNUM, MIPS_LAST_ARG_REGNUM changes References: <1030519215125.ZM24993@localhost.localdomain> <3ECBA69B.1060108@redhat.com> <1030521163655.ZM31364@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-05/txt/msg00391.txt.bz2 > On May 21, 12:17pm, Andrew Cagney wrote: > > >> > This is patch 2 of many more to come. It depends upon >> > http://sources.redhat.com/ml/gdb-patches/2003-05/msg00268.html. >> > >> > Okay? > >> >> Per my earlier comment, I don't think this one is right. I don't think >> things like LAST_ARG_REGNUM belong in that cooked/raw reg structure. >> Instead, they should exist out side it. >> >> If the code really wants to differentiate between the raw and cooked >> register number, why not use the more explicit: >> >> rawnum->gp0_regnum + tdep->last_arg_regnum > > > So, last_arg_regnum represents a count of the number of argument > registers? It's an offset from register 0. However, I think if the first patch is sorted out, this will fallout. Andrew > That's fine (at the moment anyway) for the GPRs, but it doesn't work > for the FPRs. For o32, I have things arranged so that there are a > total of 16 cooked FPRs and 32 raw FPRs. Therefore, argument register > counts will be different between cooked vs raw. IMO, it really does > make sense to put these values into the cooked/raw structure. I'm > having difficulty understanding why you're objecting to this layout. > > Kevin >