Re: Remote Target Protocol 'g' & 'P' Packets Broken for PowerPC!!!!!

[Andrew Cagney <ac131313 at cygnus dot com>]

Nick Duffek wrote:
> 
> On 24-Oct-2000, Steven Johnson wrote:
> 
> >The Prime culprits being PPC_UISA_SPRS where there is a reg placeholder
> >R0 at the end of the entry which is a non existent register and is never
> >shown.

Check for something, anything, that will cause GDBs RAW_REGISTER_BYTES
to change.  In a multi-arch situtation this is really easy to do.  The
fact that the such changes can affect the G packets interpretation is a
known and really serious design flaw (and dates back to when GDB only
ran on a VAX).

Decoupling the way remote.c interprets RAW_REGISTER_BYTES from the way
it decodes G (et.al.) packets is on my (and probably a few others)
things todo today lists.

	Andrew



> As you've observed, there isn't a one-to-one correspondence between
> register numbers and offsets in the registers[] buffer.
> 
> In particular, for the 860, rs6000-tdep.c doesn't actually allocate space
> for nonexistent registers like R0 and R64(asr) in registers[], but those
> registers still have numbers assigned to them.
> 
> (The "Calculate byte offsets in raw register array" part of
> rs6000_gdbarch_init() handles the space allocation.)
> 
> Looking at store_register_using_P() and remote_fetch_registers() in
> remote.c, I don't see how they're broken as long as the stub uses the same
> numbering and registers[] offsets as GDB.  But I'm not so familiar with
> the remote protocol, so perhaps I'm missing something.
> 
> Nick Duffek
> nsd@redhat.com