From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5097 invoked by alias); 2 May 2002 00:52:46 -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 5048 invoked from network); 2 May 2002 00:52:45 -0000 Received: from unknown (HELO cygnus.com) (205.180.83.203) by sources.redhat.com with SMTP; 2 May 2002 00:52:45 -0000 Received: from localhost.redhat.com (romulus.sfbay.redhat.com [172.16.27.251]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id RAA07338; Wed, 1 May 2002 17:52:37 -0700 (PDT) Received: by localhost.redhat.com (Postfix, from userid 469) id 48F8F10A8C; Wed, 1 May 2002 20:52:03 -0400 (EDT) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15568.36275.110744.510692@localhost.redhat.com> Date: Wed, 01 May 2002 17:52:00 -0000 To: joern.rennecke@st.com Cc: gcc@gcc.gnu.org, gdb@sources.redhat.com, aoliva@redhat.com, ezannoni@redhat.com, bje@redhat.com, ac131313@cygnus.com Subject: Re: SH5 compact register numbering in gcc -> gdb interface In-Reply-To: <3CCED903.294513BE@st.com> References: <3CCED903.294513BE@st.com> X-SW-Source: 2002-05/txt/msg00003.txt.bz2 Joern Rennecke writes: > The numbers currently used to encode registers in the debug information > for SH5compact seem quite arbitrary. I see that they correspond > to the current pseudo register scheme in gdb, but this is going > to change when a unified interface for SH and SH64 is created. > What I have in mind for the simulator interface is to keep the > current SH1-SH4, SH[3]-DSP register numbers, (and also keep the > corresponding gdb pseudo register numbers), and start the SH64 > numbers at 128. > The SHcompact simulator register numbers can be the same as for SH4. > However, this exposes the arbitrariness of the gcc->gdb interface, > and I think now - before the integration of the simulator and gdb > port into the FSF sources - is our last chance to change it. > Hmmm, in theory the numbers in the debug info for sh5 don't need to be the same as the gdb ones. In theory GDB could deal with this by defining its own mapping with the macro DWARF2_REG_TO_REGNUM. However this is only a piece of the puzzle... see below > The SHcompact registers are all mapped to SH5media registers, > and therefore it seems most natural to use the numbers used > for these SH5media registers also in SHcompact code - indeed, > this is currently already done for the general purpose registers. > The only odd one out is MACH, which resides in the upper 32 bit > of R17; for this I propose to use number 141. > This numbering also has the advantage that all SH5compact registers > except MACH can be encoded with LEB128 in a single byte. > > compact reg current # sh5 equiv proposed # > -----------+-----------+------------+------------------ > R0 .. R15 0 .. 15 R0 .. R15 0 .. 15 > FR0 .. FR15 245 .. 260 FR0 .. FR15 77 .. 92 > XD0 .. XD14 289 .. 296 DR16 .. DR30 93 .. 107 (odd only) > PR 241 R18 18 > T 242 R19 19 > GBR 238 R16 16 > MACH 239 R17(high) 141 > MACL 240 R17(low) 17 > FPUL 244 FR32 109 > If you change the compact registers numbers in the debug info to be the same as the (or to reuse) numbers for sh media, then the gdb port will be badly broken. (Never mind for the moment that the current mapping is screwed up, I agree, but for opposite reasons to yours...I'll explain in a second.) The reason that the gdb port will break is that gdb needs to know the ABI currently in use when reading or writing a register, because the register sizes are different. For this reason GDB relies on the the register numbers being disjoint for compact and media modes. Now, looking at the current mapping, the 2 sets are not disjoint, and this is the reason for which gdb is failing some tests currently. I hadn't closely looked at this mapping before, unfortunately. In case of general registers gdb gets very confused between compact and media mode. It doesn't know how long the register is when trying to read the value of a variable stored in a general register because the debug information is exactly the same for the 2 modes. The only way to get around this, which your re-mapping would also require, is to have *always* available the PC of the frame relative to which we are reading the register, because the PC being odd/even tells us which ABI, and therefore which register size, is in use. At this time I have identified 2 places in GDB where I have a hack in place to work around this overlap of register sets. However I haven't submitted the hacks publicly, because they are pretty bad. Anyway, there are plenty of other places where a PC value (i.e. a frame parameter) would need to be added to gdb internal functions, to get this right. As far as the sh-tdep.c code goes, this also would have to be extensively rewritten if the assumption that the register sets are disjoint is dropped. So, I would be opposed to such a change. I don't think renumbering the simulator registers would have such a devastating effect. Anyway, I agree with you that the current version of the SH_DBX_REGISTER_NUMBER is not the most logic arrangement. The floating point registers are mapped to a separate subset, but the general registers are not. All the following registers should be mapped to a register set disjoint from the sh media one. Right now they are not. SH COMPACT MODE (ISA 16) 221 r0_c, r1_c, r2_c, r3_c, r4_c, r5_c, r6_c, r7_c, 229 r8_c, r9_c, r10_c, r11_c, r12_c, r13_c, r14_c, r15_c, 237 pc_c, 238 gbr_c, mach_c, macl_c, pr_c, t_c, 243 fpscr_c, fpul_c, 245 fr0_c, fr1_c, fr2_c, fr3_c, fr4_c, fr5_c, fr6_c, fr7_c, 253 fr8_c, fr9_c, fr10_c, fr11_c, fr12_c, fr13_c, fr14_c, fr15_c 261 dr0_c, dr2_c, dr4_c, dr6_c, dr8_c, dr10_c, dr12_c, dr14_c 269 fv0_c, fv4_c, fv8_c, fv12_c I believe something like this would work. Elena Index: sh.h =================================================================== RCS file: /cvs/uberbaum/gcc/config/sh/sh.h,v retrieving revision 1.137 diff -u -r1.137 sh.h --- sh.h 3 Mar 2002 21:10:04 -0000 1.137 +++ sh.h 2 May 2002 00:49:21 -0000 @@ -2896,6 +2896,8 @@ #define DBX_REGISTER_NUMBER(REGNO) \ (GENERAL_REGISTER_P (REGNO) \ ? ((REGNO) - FIRST_GENERAL_REG) \ + ? ((REGNO) - FIRST_GENERAL_REG + (TARGET_SH5 ? (TARGET_SHCOMPACT ? 221 \ + : 0) : 0)) \ : FP_REGISTER_P (REGNO) \ ? ((REGNO) - FIRST_FP_REG + (TARGET_SH5 ? (TARGET_SHCOMPACT ? 245 \ : 77) : 25)) \