From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19041 invoked by alias); 7 Mar 2003 19:13:42 -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 19020 invoked from network); 7 Mar 2003 19:13:41 -0000 Received: from unknown (HELO localhost.redhat.com) (172.16.49.200) by 172.16.49.205 with SMTP; 7 Mar 2003 19:13:41 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 9FDFD2A9C; Fri, 7 Mar 2003 14:13:37 -0500 (EST) Message-ID: <3E68EF61.6070601@redhat.com> Date: Fri, 07 Mar 2003 19:13: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-tdep.c: Add dwarf/dwarf2 regnum mapping functions References: <1030304211701.ZM24618@localhost.localdomain> <3E68D0FD.2010809@redhat.com> <1030307175146.ZM16168@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-03/txt/msg00176.txt.bz2 >> mips_tdep could certainly gain a local tdep->fp0_regnum though. > > > Did you notice the references to FP0_REGNUM in mips-linux-tdep.c and > mips-nat.c?. If we do as you suggest, an access method will need to > be added to mips-tdep.h for getting at tdep->fp0_regnum (since you > refuse to export the mips tdep struct). Also, all occurrences of > FP0_REGNUM in mips-linux-tdep.c and mips-nat.c will need to be > rewritten to use this access method. I ignored everything that wasn't core. Such a rewrite goes on my to-do list. > Certainly all of this could be done, but the need to know the first > floating point register number is something that's shared among a > number of ports. Doesn't it makes sense to define (as has already > been done) a common mechanism for determining this register number > rather than letting each port develop ad hoc methods? The problem is that FP0_REGNUM has no narrow and well defined meaning. Same problem as with SP_REGNUM, PC_REGNUM, FP_REGNUM. As a specific example. Given an ISA with 64 bit FP registers that is running a 32 bit FP ABI (debug info refers to 32 bit FP registers). /proc assumes FP0_REGNUM designates the first 64 bit [raw] FP register, yet dwarf2 assumes that FP0_REGNUM designates the first 32 bit [cooked] FP register. It doesn't work (well, ok the current mess involving register convertible kind of half sort of makes it appear to work). Per previous patches, that code needs an overhaul. Andrew