From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12408 invoked by alias); 18 Jun 2003 23:54:03 -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 12266 invoked from network); 18 Jun 2003 23:54:02 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 18 Jun 2003 23:54:02 -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 h5INs2H04543 for ; Wed, 18 Jun 2003 19:54:02 -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 h5INs2I13693 for ; Wed, 18 Jun 2003 19:54:02 -0400 Received: from localhost.localdomain (vpn50-21.rdu.redhat.com [172.16.50.21]) by pobox.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h5INs1r20236; Wed, 18 Jun 2003 19:54:01 -0400 Received: (from kev@localhost) by localhost.localdomain (8.11.6/8.11.6) id h5INrug16185; Wed, 18 Jun 2003 16:53:56 -0700 Date: Wed, 18 Jun 2003 23:54:00 -0000 From: Kevin Buettner Message-Id: <1030618235356.ZM16184@localhost.localdomain> In-Reply-To: Andrew Cagney "Re: [patch rfc] Add NUM_REGS pseudo regs to MIPS" (Jun 18, 12:35pm) References: <3EEDE3BE.8070207@redhat.com> <1030618043229.ZM11543@localhost.localdomain> <3EF094CE.3080902@redhat.com> To: Andrew Cagney Subject: Re: [patch rfc] Add NUM_REGS pseudo regs to MIPS Cc: gdb-patches@sources.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-06/txt/msg00613.txt.bz2 On Jun 18, 12:35pm, Andrew Cagney wrote: > > On a big endian 32 bit ABI, the compiler spills floating-point > > registers as a pair and as a floating-point double. Because the > > target is big-endian, this leads to the register pair being stored > > in reverse order vis: $fN ||| $fN+1 are stored as $fN+1 and then > > $fN. > > > > The code doesn't do that, it gets the address of $fN correct, but > > $fN+1 is 8 bytes out. Outch! [...] > Committing it will make, the already impossible task of getting the MIPS > frame code using the unwinders, even harder. Okay, I see what you mean. Proceed as you see fit. (I'm going to step aside and let you handle the integration of whatever portions of my patch that you wish to retain.) Kevin