Re: [WIP/RFC] MIPS registers overhaul

[Andrew Cagney <ac131313@redhat.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