From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26212 invoked by alias); 10 May 2002 10:09:31 -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 26133 invoked from network); 10 May 2002 10:09:23 -0000 Received: from unknown (HELO beta.dmz-eu.st.com) (164.129.1.35) by sources.redhat.com with SMTP; 10 May 2002 10:09:23 -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 21601526D; Fri, 10 May 2002 10:09:22 +0000 (GMT) Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 0) id B783462A6; Fri, 10 May 2002 10:09:21 +0000 (GMT) Received: from thistle.bri.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id DFB281848; Fri, 10 May 2002 10:09:20 +0000 (GMT) Received: from [164.129.8.14] (helo=masterwort) by thistle.bristol.st.com with esmtp (Exim 3.03 #5) id 1767Kx-0001i4-00; Fri, 10 May 2002 11:09:19 +0100 Received: from [164.129.14.84] (helo=st.com) by masterwort with asmtp (Exim 3.22 #1) id 1767Kx-0001lY-00; Fri, 10 May 2002 11:09:19 +0100 Message-ID: <3CDB9C75.27044AE@st.com> Date: Fri, 10 May 2002 03:09:00 -0000 From: Joern Rennecke Organization: SuperH UK Ltd. X-Accept-Language: en MIME-Version: 1.0 To: ezannoni@redhat.com Cc: ac131313@cygnus.com, binutils@sources.redhat.com, aoliva@redhat.com, gcc@gcc.gnu.org, gdb@sources.redhat.com, bje@redhat.com Subject: Re: SH5 compact register numbering in gcc -> gdb interface - include/elf/sh.h ? References: <3CCED903.294513BE@st.com> <15568.36275.110744.510692@localhost.redhat.com> <3CD12BF8.7E1650C1@st.com> <3CD7EB51.7816DD1@st.com> <3CD803BC.5060900@cygnus.com> <3CD823D1.FC1E3717@st.com> <3CD85192.7020100@cygnus.com> <3CDAEDA4.3DE4A2D5@st.com> <15578.63785.429521.553723@localhost.redhat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-05/txt/msg00097.txt.bz2 ezannoni@redhat.com wrote: > > Joern Rennecke writes: > > To give gcc and gdb a common interface, it is best put into a header file that > > but > > gdb/sh-tdep and gcc/config/sh/sh.h (can) include. > > > > I thought of putting it into include/elg/sh.h, since elf is now the predominant > > object format for SH gcc. Or should we start something like an include/dwarf > > directory? > > But then, it's not strictly dwarf either, since these register numbers are > > also used for stabs debugging info (in the SH1..SH4 coff toolchain, or if > > you ask specifically for stabs.) > > > > I think include/gcc-sh64.h or include/gdb-sh64.h could be OK. Would match the > include/sim-sh64.h file. > > > --- ../include/elf/sh.h Thu May 9 22:22:18 2002 > > *************** START_RELOC_NUMBERS (elf_sh_reloc_type) > > *** 218,221 **** > > --- 218,247 ---- > > RELOC_NUMBER (R_SH_64_PCREL, 255) > > END_RELOC_NUMBERS (R_SH_max) > > > > + enum > > + { > > + SH_DEBUG_INFO_R0 = 0, > > + SH_DEBUG_INFO_PR = 17, > > + SH_DEBUG_INFO_GBR = 18, > > + SH_DEBUG_INFO_MACH_BIG = 20, SH_DEBUG_INFO_MACL, SH_DEBUG_INFO_MACH_LITTLE, > > This will break gdb. Register 22 ir SR. What are these registers? gcc does not emit debug information for SR - if it was encountered in DBX_REGISTER_NUMBER, the compiler would abort. So we don't actually have a number allocated in the interface right now, and if we need one, we are free to choose any. > Doesn't SH have only mach and macl? Yes, it has only mach and macl. But you could hold a 64 bit value in this register pair, in which case MACH always holds the high part and MACL holds the low part. So the idea is to use SH_DEBUG_INFO_MACH_BIG for big endian, and SH_DEBUG_INFO_MACH_LITTLE for little endian. This way, it is clear where low and high part are. both SH_DEBUG_INFO_MACH_BIG and SH_DEBUG_INFO_MACH_LITTLE are then mapped to gdb's MACH. Note that SH_DEBUG_INFO_MACH_BIG is the old MACH number, and SH_DEBUG_INFO_MACL is the old MACL number, so we have full backwards compatibility. Having both this backwards compatibility and the ability to represent a 64 bit value in MACH/MACL for little endian was the point of using 22 for SH_DEBUG_INFO_MACH_LITTLE. > > + SH64_DEBUG_INFO_R0 = 0, > > + SH64_DEBUG_INFO_TR0 = 68, > > + SH64_DEBUG_INFO_FR0 = 77, > > + SH64_DEBUG_INFO_T_C = 19, > > + SH64_DEBUG_INFO_XF0_C = SH64_DEBUG_INFO_FR0 + 16, > > + SH64_DEBUG_INFO_FPUL_C = SH64_DEBUG_INFO_FR0 + 32, > > + SH64_DEBUG_INFO_R0_C = 141, > > + SH64_DEBUG_INFO_GBR_C = 157, > > + SH64_DEBUG_INFO_MACH_C_BIG, SH64_DEBUG_INFO_MACL_C, > > + SH64_DEBUG_INFO_MACH_C_LITTLE, > > + SH64_DEBUG_INFO_PR_C, SH_DEBUG_INFO_FPSCR_C > > + }; > > #endif > > What is the advantage of reusing media numbers for compact registers? The numbers are reused where the registers are actually identical. Thus, there is actually less work for gcc and gdb to encode and decode these registers. > This also wouldn't work with the current code, because it is assumed > that the register sets are disjoint. I see that you have made disjoint I don't know what you need disjoint registers for, when the size and location of the register is the same in either mode. What part of the code makes assumptions about further disjointness? -- -------------------------- SuperH 2430 Aztec West / Almondsbury / BRISTOL / BS32 4AQ T:+44 1454 462330