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

Andrew Cagney
2002-05-09T19:49:52Z

> 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