From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15507 invoked by alias); 4 May 2002 05:21:26 -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 15498 invoked from network); 4 May 2002 05:21:25 -0000 Received: from unknown (HELO potter.sfbay.redhat.com) (205.180.83.107) by sources.redhat.com with SMTP; 4 May 2002 05:21:25 -0000 Received: from livre.redhat.lsd.ic.unicamp.br (vpn3-5.sfbay.redhat.com [172.16.25.5]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id g445KIv20744; Fri, 3 May 2002 22:20:19 -0700 Received: (from aoliva@localhost) by livre.redhat.lsd.ic.unicamp.br (8.11.6/8.11.6) id g445L8F05757; Sat, 4 May 2002 02:21:08 -0300 To: joern.rennecke@st.com Cc: ezannoni@redhat.com, gcc@gcc.gnu.org, gdb@sources.redhat.com, bje@redhat.com, ac131313@cygnus.com Subject: Re: SH5 compact register numbering in gcc -> gdb interface References: <3CCED903.294513BE@st.com> <15568.36275.110744.510692@localhost.redhat.com> <3CD12BF8.7E1650C1@st.com> From: Alexandre Oliva Organization: GCC Team, Red Hat Date: Fri, 03 May 2002 22:21:00 -0000 In-Reply-To: <3CD12BF8.7E1650C1@st.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-05/txt/msg00038.txt.bz2 On May 2, 2002, Joern Rennecke wrote: > Right, so we do need the general purpose register to have different > numbers, because of their different size. The size shouldn't really > matter for single integer values inside a register, but it does when you > need more than one register for SHcompact, or you are describing register > saves / restores. The register numbering used by GCC is definitely arbitrary. I hadn't even considered there might be reasons for it not to be, for which I apologize. It's a bit unfortunate that this has come up when we're this close to the first GCC release to include the SH5 port. I'm not sure we have enough time to come up with a solution, nor whether Mark would accept it in the branch. It would be too bad if GDB couldn't debug code compiled by GCC 3.1. Perhaps we can come up with a backward-compatible register mapping, even if GDB would work in a degraded mode when the current register numbering is in use. > I can imagine circumstances where you would want to push GBR or > FPSCR in the prologue, so it might make sense to have a number for them. Especially if we move to some more efficient exception handling mechanism. But there are going to be other interesting problems to solve to be able to do it. I don't think the current infrastructure can handle registers saved with different sizes in the stack (think SHmedia calls SHcompact calls SHmedia, such that we have to restore say r10 from the SHcompact frame, in which it was saved as a 32-bit value). > FPUL is the same size as FR32, so it makes sense to describe it as FR32, > since that is what it really is. > PR would only appear as a saved register, but I gather that gdb needs to know > the size it has been saved in, so it makes sense to have a separate number. Agreed. > MACH and MACL are a rather unique problem. When you put a 64 bit value into > them, you can only describe this properly if you are using big endian. > This could be fixed e,g, by having a third register, i.e. > big endian MACH / MACL / little endian MACH. Sounds like a reasonable solution. -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{cygnus.com, redhat.com} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer