RE: mcore registers

[LaPonsey Brian-ra4951 <Brian.Laponsey@motorola.com>]

> Can you post the output from "maint print registers"?  If these 
> registers are last, the stub can send back a short register 
> packet

The pc is the last, not cr31 --

(gdb) maint print registers
 Name         Nr  Rel Offset    Size  Type
 r0            0    0      0       4  int
... (snip) ...
 r15          15   15     60       4  int
 ar0          16   16     64       4  int
... (snip) ...
 ar15         31   31    124       4  int
 psr          32   32    128       4  int
 vbr          33   33    132       4  int
 epsr         34   34    136       4  int
 fpsr         35   35    140       4  int
 epc          36   36    144       4  int
 fpc          37   37    148       4  int
 ss0          38   38    152       4  int
 ss1          39   39    156       4  int
 ss2          40   40    160       4  int
 ss3          41   41    164       4  int
 ss4          42   42    168       4  int
 gcr          43   43    172       4  int
 gsr          44   44    176       4  int
 cr13       45   45    180       4  int
... (snip)
 cr31         63   63    252       4  int
 pc           64   64    256       4  int


> longer packet back to the stub).  It may also be possible to 
> run length 
> encode (phrase?) the "x" indicating that the the missing 
> registers are 
> not available.

I had planned on eventually implementing the run-length encoding (using the '*' symbol).  All of the non-existent registers just get reported as containing zeroes, so RLL would compress this consistently.  Maybe it's time to get busy on that.  I was hoping for a fix that not only improves performance, but also accurately reflects how the mcore is actually built.

> If GDB, without other changes, dropped those registers, compatibility 
> with existing stubs would be broken.

OK.  I know of only three tools that talk to mcore using the remote serial protocol, and all parties involved say that patching gdb is OK.  But there may be others out there, as you point out, so it's not possible to guarantee that everybody will stay happy.  If we can't fix gdb, then I'll just get busy and program around the problem.

Brian