Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Joern Rennecke <joern.rennecke@st.com>
To: ac131313@cygnus.com
Cc: gdb@sources.redhat.com
Subject: Re: [Fwd: Re: SH5 compact register numbering in gcc -> gdb interface]
Date: Thu, 09 May 2002 06:16:00 -0000	[thread overview]
Message-ID: <3CDA76AA.16974781@st.com> (raw)
In-Reply-To: <3CD97C16.6050801@cygnus.com>

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


  reply	other threads:[~2002-05-09 13:16 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-05-08  2:47 Joern Rennecke
2002-05-08 12:27 ` Andrew Cagney
2002-05-09  6:16   ` Joern Rennecke [this message]
2002-05-09 12:49     ` Andrew Cagney
2002-05-09 12:11 ` Andrew Cagney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3CDA76AA.16974781@st.com \
    --to=joern.rennecke@st.com \
    --cc=ac131313@cygnus.com \
    --cc=gdb@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox