From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 513 invoked by alias); 8 May 2002 19:27:15 -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 506 invoked from network); 8 May 2002 19:27:14 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 8 May 2002 19:27:14 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 26B7A3D2F; Wed, 8 May 2002 15:27:19 -0400 (EDT) Message-ID: <3CD97C16.6050801@cygnus.com> Date: Wed, 08 May 2002 12:27:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0rc1) Gecko/20020429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: joern.rennecke@st.com Cc: gdb@sources.redhat.com Subject: Re: [Fwd: Re: SH5 compact register numbering in gcc -> gdb interface] References: <3CD8F3EC.1FE421BB@st.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-05/txt/msg00079.txt.bz2 > Sorry, I forgot to copy this to the list. > > -------- Original Message -------- > Message-ID: <3CD820CD.9FC46E7F@st.com> > Date: Tue, 07 May 2002 19:45:33 +0100 > From: Joern Rennecke > Reply-To: joern.rennecke@st.com > Organization: SuperH UK Ltd. > X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10 i686) > X-Accept-Language: en > MIME-Version: 1.0 > To: 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> > <3CD80B1D.3020902@cygnus.com> > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > > ac131313@cygnus.com wrote: > >> Just FYI, the thing that controls the internal register layout of GDB is >> [currently] the remote protocol. If you try to wire down GDB's internal >> register numbers to match the simulator, you'll likely break GDB's >> compatibility with existing remote targets. > > > Note, I'm not proposing to change the internal numbering for the SH1..SH4 > targets, only for the SH5 target. Ok, I guess. >> While this limitation is being worked on, it doesn't affect the GDB <-> >> sim maping - that can already be adjusted independant of the other >> register numbering schema. > > > But should it? > > The patches from Elena Zannoni only define one layout for SH5 registers, > which conflicts with the SH4 register layout. So, currently, the register > layout in gdb is the same for simulator and remote targets for any given > SH processor. > > I understand that we don't have much old tools to be > compatible with for SH5, so we can still change the interface. And the > ambiguity issues that apply to the simulator interface apply as well > to remote targets, so I don't understand why you would require an > interface with unambigous register numbers for the simulator, while > rejecting it for remote targets. I'm not sure what you mean here. 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. enjoy, Andrew