mcore registers
LaPonsey Brian-ra4951
Brian.Laponsey@motorola.com
Tue Sep 30 08:21:00 GMT 2003
> 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
More information about the Gdb-patches
mailing list