From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7843 invoked by alias); 29 May 2003 19:49:25 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 7787 invoked from network); 29 May 2003 19:49:23 -0000 Received: from unknown (HELO stardust.solidas.com) (217.13.28.68) by sources.redhat.com with SMTP; 29 May 2003 19:49:23 -0000 Received: from solidas.com (217-13-28-83.dd.nextgentel.com [217.13.28.83]) (authenticated) by stardust.solidas.com (8.11.6/8.11.6) with ESMTP id h4TJnFl02106; Thu, 29 May 2003 21:49:15 +0200 Message-ID: <3ED6644D.2030201@solidas.com> Date: Thu, 29 May 2003 19:49:00 -0000 From: "Svein E. Seldal" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030521 Debian/1.3.1-1 X-Accept-Language: en MIME-Version: 1.0 To: Andrew Cagney CC: gdb@sources.redhat.com Subject: Re: FP aliases References: <3ED54A80.3030900@solidas.com> <3ED63129.9020500@redhat.com> In-Reply-To: <3ED63129.9020500@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-05/txt/msg00400.txt.bz2 Andrew Cagney wrote: > If your architecture does not have a $fp, do not try to provide it. GDB > will map $fp onto the frame's base address (as defined by the debug info). > Only include $fp in the register names when there is a register, as > defined by the ISA, that has the name "fp". > > The d10v doesn't have a register called FP, so doesn't provide "fp". > Instead, $fp is mapped onto the frame's base address. Well, the trick is that tic4x-gcc assigns ar3 as an fp register (at all times), so you wind up stuck in the middle here. You have an FP-like register, yet it's not named FP. But I've rough-ported the d10v unwind mechanisms to the tic4x port, and it seems like I am able to work it out without the fp register. (Still, I need to understand those unwind things..) > Yes. An architecture function is deprecated when either: it isn't > needed at all (as with FP_REGNUM, READ_FP); or has been made redundant > by a newer mechanism. Yes, and its these new mechanisms I'm trying to work out. I'll take a look at the i386 port, and see if I'm able to resolve its functionality from that. Svein