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

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

[Joern Rennecke]

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.
> 
> 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.

-- 
--------------------------
SuperH
2430 Aztec West / Almondsbury / BRISTOL / BS32 4AQ
T:+44 1454 462330

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

[Andrew Cagney]

> 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

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

[Joern Rennecke]

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

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

[Andrew Cagney]

> 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).

The reason I recommended doing something to the simulator register 
numbers was to detect problems when combining SH* gdb with a simulator 
in a specific mode.

For instance, given a SIM modeling the SH4 ISA, it doesn't make sense 
for GDB to try to read SH5 hardware registers - the SIM doesn't have 
them.  By assigning different sim_regnum's to each ISA, GDB/SIM can 
detect a conflict.

There are other ways of handling this, I happen to think that this is 
the simplest.

> 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.

This isn't new.  For a given ISA [0..NUM_REGS) are hardware/raw 
registers.  Pseudo-registers can't be put before this.  Making the 
number of registers sparse means having to iterate over gaps.

> 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.

Yes.  For GDB, having to do this is just another fact of life :-)

> 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?

Remember, GDB has a number of interfaces (sim, remote, dwarf2, stabs, 
mdebug, ptrace, ....) and (except for the remote protocol) each will 
have its own register numbering scheme.  While trying to make all 
numbering schemes identical sounds good in theory it turns out to be 
impossible in reality.  Hence, I think, pinning down specific interfaces 
is more important than trying to go for a single unified numbering scheme.

Once remote.c has been ``fixed'' it will be possible to improve things 
though.

enjoy,
Andrew

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

[Andrew Cagney]

Just BTW,

GDB now has a ``set trust-read-only-sections'' command that has a 
similar effect to dwarf2cfi.

Andrew