Re: [WIP/RFC] MIPS registers overhaul

Andrew Cagney
2003-05-23T20:45:19Z

> 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