Re: [WIP/RFC] MIPS registers overhaul

[Andrew Cagney <ac131313 at redhat dot com>]

> On Fri, May 23, 2003 at 02:21:49PM -0400, Andrew Cagney wrote:
>
> >
>
> > >>Er, it's the same deal as for SPARC.  If GDB is built against the 64 bit 
> > >>debug interface, it can debug both 32 and 64 bit applications.  This is 
> > >>the debuggers view, not the program being run's view.
>
> > >
> > >
> > >But the point is that the debugger's view of a 32-bit application on
> > >MIPS is of a 32-bit ISA.  That's all that's available.  You get 32-bit
> > >registers from the kernel.
>
> > That isn't true.  CF the embedded case.  The ISA can be 64 bits, but the 
> > ABI 32 bits.  This argument is becomming circular.
>
>
> I'm not talking about the embedded case!  I never said that we should
> always use a 32-bit protocol when debugging a 32-bit ABI.  I said that
> in this case, using rda or gdbserver on a hosted system, it doesn't
> make any sense to use the 64-bit protocol.

GDB shouldn't be differentiating.  It's a remote.c problem.

> > GDB has to make a choice.  Either hack the tdep code so that it tries to 
> > get the user, register, and target ABIs to all line up, or select an 
> > underlying canonical ISA and expect targets to map their register values 
> > onto that.  Selecting a definitive 64 bit ISA means that the tdep code 
> > works in all cases - the target is made responsibile for resolving self 
> > inflicted esoteric edge cases.
>
>
> Then why have the 32-bit protocol at all, besides compatibility with
> existing stubs?  Just waste the transfer time for the unused bits all
> the time.

If the self inflicting esoteric remote target and the regcache were no 
longer connected at the hip, more efficient register protocols could be 
used.  Anyway some packing techniques:

- T packets (available now)
- proposed short T register values
- proposed [pP] packet to request additional registers
- proposed ``!'' [for network byte ordered] register values
- use of run-length encoding (available now?)
- use of -1 to encode 0xffffffffffffffff (available now?)

> > Note here that the self inflicting esoteric target is remote.c, it is 
> > still tied to the register cache at the hip :-(

Andrew