From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29396 invoked by alias); 9 May 2002 13:16: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 29340 invoked from network); 9 May 2002 13:15:56 -0000 Received: from unknown (HELO beta.dmz-eu.st.com) (164.129.1.35) by sources.redhat.com with SMTP; 9 May 2002 13:15:56 -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 B376C4C17; Thu, 9 May 2002 13:15:48 +0000 (GMT) Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 0) id 588906198; Thu, 9 May 2002 13:15:48 +0000 (GMT) Received: from thistle.bri.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id DAE8A184E; Thu, 9 May 2002 13:15:47 +0000 (GMT) Received: from [164.129.8.14] (helo=masterwort) by thistle.bristol.st.com with esmtp (Exim 3.03 #5) id 175nlr-00020p-00; Thu, 09 May 2002 14:15:47 +0100 Received: from [164.129.14.84] (helo=st.com) by masterwort with asmtp (Exim 3.22 #1) id 175nlq-0007eR-00; Thu, 09 May 2002 14:15:46 +0100 Message-ID: <3CDA76AA.16974781@st.com> Date: Thu, 09 May 2002 06:16:00 -0000 From: Joern Rennecke Reply-To: joern.rennecke@st.com Organization: SuperH UK Ltd. X-Accept-Language: en MIME-Version: 1.0 To: ac131313@cygnus.com Cc: gdb@sources.redhat.com Subject: Re: [Fwd: Re: SH5 compact register numbering in gcc -> gdb interface] References: <3CD8F3EC.1FE421BB@st.com> <3CD97C16.6050801@cygnus.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-05/txt/msg00080.txt.bz2 ac131313@cygnus.com wrote: > > > Sorry, I forgot to copy this to the list. > > > Any way, with what ever is proposed, just remember that remote.c, the > remote protocol, and random other bits of GDB currently interact in > pretty nasty ways. The code very much assumes that GDB's internal > numbers correspond to the remote protocol numbers; and the remote > register packet register offsets correspond to GDB's internal register > buffer offsets [ulgh]. > > The [unfortunate] consequence is that the first [0..NUM_REGS) of the GDB > internal registers need to: > - be hard/raw registers i.e. SH5media > - occure first in the register buffer > - the numbers shouldn't be sparse > After the hard/raw registers come the pseudo-registers (such as > SH5compact registers). Those registers are not transfered via the > remote protocol. Let me get this straight. You want a unified simulator interface, not reusing register numbers for registers with different sizes Since the SH1..SH4 numbers are already assigned for a bunch of 32 bit registers, the SH5 simulator register numbers will have to start after the SH4 ones, i.e. the register numbers for the SH5 simulator have to be sparse (have a large gap at the start). Now you are saying that the remote protocol does not allow to start the registers with a number other than zero, and the register numbers should not be sparse. Thus, by unifing the register numbering in the SH1-4 / SH5 simulator interface, we must make the register numbering SH5 simulator interface different from the one in the SH5 remote interface. It appears to me that we make the entire mess even harder to maintain this way. Why is having different register numbering for the same processor for simulator / remote better than having different numbering between the SH1..SH4 simulator vs. the SH5 simulator? -- -------------------------- SuperH 2430 Aztec West / Almondsbury / BRISTOL / BS32 4AQ T:+44 1454 462330