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

[Alexandre Oliva <aoliva@redhat.com>]

On May  2, 2002, Joern Rennecke <joern.rennecke@st.com> wrote:

> Right, so we do need the general purpose register to have different
> numbers, because of their different size.  The size shouldn't really
> matter for single integer values inside a register, but it does when you
> need more than one register for SHcompact, or you are describing register
> saves / restores.

The register numbering used by GCC is definitely arbitrary.  I hadn't
even considered there might be reasons for it not to be, for which I
apologize.  It's a bit unfortunate that this has come up when we're
this close to the first GCC release to include the SH5 port.  I'm not
sure we have enough time to come up with a solution, nor whether Mark
would accept it in the branch.  It would be too bad if GDB couldn't
debug code compiled by GCC 3.1.  Perhaps we can come up with a
backward-compatible register mapping, even if GDB would work in a
degraded mode when the current register numbering is in use.

> I can imagine circumstances where you would want to push GBR or
> FPSCR in the prologue, so it might make sense to have a number for them.

Especially if we move to some more efficient exception handling
mechanism.  But there are going to be other interesting problems to
solve to be able to do it.  I don't think the current infrastructure
can handle registers saved with different sizes in the stack (think
SHmedia calls SHcompact calls SHmedia, such that we have to restore
say r10 from the SHcompact frame, in which it was saved as a 32-bit
value).

> FPUL is the same size as FR32, so it makes sense to describe it as FR32,
> since that is what it really is.

> PR would only appear as a saved register, but I gather that gdb needs to know
> the size it has been saved in, so it makes sense to have a separate number.

Agreed.

> MACH and MACL are a rather unique problem.  When you put a 64 bit value into
> them, you can only describe this properly if you are using big endian.
> This could be fixed e,g, by having a third register, i.e.
> big endian MACH / MACL / little endian MACH.

Sounds like a reasonable solution.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer