From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16202 invoked by alias); 7 May 2002 14:57:04 -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 16101 invoked from network); 7 May 2002 14:56:50 -0000 Received: from unknown (HELO beta.dmz-eu.st.com) (164.129.1.35) by sources.redhat.com with SMTP; 7 May 2002 14:56:50 -0000 Received: from zeta.dmz-eu.st.com (zeta.dmz-eu.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with SMTP id EE54A4B44; Tue, 7 May 2002 14:56:42 +0000 (GMT) Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 0) id AA8D661FC; Tue, 7 May 2002 14:56:42 +0000 (GMT) Received: from thistle.bri.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id C9AA61848; Tue, 7 May 2002 14:56:41 +0000 (GMT) Received: from [164.129.8.14] (helo=masterwort) by thistle.bristol.st.com with esmtp (Exim 3.03 #5) id 1756OO-0003hX-00; Tue, 07 May 2002 15:56:40 +0100 Received: from [164.129.14.84] (helo=st.com) by masterwort with asmtp (Exim 3.22 #1) id 1756OO-0003cP-00; Tue, 07 May 2002 15:56:40 +0100 Message-ID: <3CD7EB51.7816DD1@st.com> Date: Tue, 07 May 2002 07:57:00 -0000 From: Joern Rennecke Reply-To: joern.rennecke@st.com Organization: SuperH UK Ltd. X-Accept-Language: en MIME-Version: 1.0 To: aoliva@redhat.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> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-05/txt/msg00049.txt.bz2 aoliva@redhat.com wrote: > 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 was proposing only to change the SHcompact mapping, so that code compiled with the default options won't be affected. Moreover, there are still a number of bugs in gcc 3.1 that affect the SH5 port, some of which can only be fixed with changes to the machine-independent sources. I am working on this, but it is not feasible to finish this work in time for gcc 3.1 . Hence, I'd expect some gcc 3.2 snapshots to be better for SH5 than gcc 3.1 for production code. Another reason to switch to a post 3.1 compiler will be debugging speed. The prologue-disassembling slows backtraces considerably when debugging on real hardware. We are currently working on SH gcc emitting proper cfi information, and gdb making use of it. For SH4 this has already proved to make quite an improvement, and the gcc bug fixes for this are among the next patches I intend to put into the FSF gcc repository. -- -------------------------- SuperH 2430 Aztec West / Almondsbury / BRISTOL / BS32 4AQ T:+44 1454 462330