Re: [Fwd: Re: SH5 compact register numbering in gcc -> gdb interface]

[Andrew Cagney <ac131313@cygnus.com>]

> 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 <joern.rennecke@st.com>
> 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