RE: mcore registers

RE: mcore registers

[LaPonsey Brian-ra4951]

> Ok.  Note that GDB doesn't run length encode.  Instead it 

Oh.  I was depending on the manual being right - I didn't know the RLE feature was non-functional.  You just saved me having to find that out the hard way.

> tries to use 
> the "P" packet.  If not already, also look at the "T..." response to 
> things like continue.

Right, I could recode the T packet responses so that they don't just cycle through all the regs.  The reg number is encoded in there, so I could skip over the non-existent ones.

Not familiar with the P packet.  Back to the fine manual.

Brian

RE: mcore registers

[LaPonsey Brian-ra4951]

> 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

Re: mcore registers

[Andrew Cagney]

>> 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 --

Doh!

> (gdb) maint print registers

>  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.

Ok.  Note that GDB doesn't run length encode.  Instead it tries to use 
the "P" packet.  If not already, also look at the "T..." response to 
things like continue.

Andrew

Re: mcore registers

[Paul Koning]

>>>>> "Andrew" == Andrew Cagney <ac131313@redhat.com> writes:

 >> 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....

 Andrew> Ok.  Note that GDB doesn't run length encode. 

Curious... I turned it on (with gdb 5.3, x86 host, mips target) and it
worked for me.  Helps a lot, too.

	 paul

Re: mcore registers

[Andrew Cagney]

>>>>>> "Andrew" == Andrew Cagney <ac131313@redhat.com> writes:
> 
> 
>  >> 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....
> 
>  Andrew> Ok.  Note that GDB doesn't run length encode. 
> 
> Curious... I turned it on (with gdb 5.3, x86 host, mips target) and it
> worked for me.  Helps a lot, too.

Let me try again. GDB won't, as far as I know, run-length-encode packets 
that it sends to the target.  It will happily accept run-length-encoded 
packets the target sends to it though.

Andrew

mcore registers

[LaPonsey Brian-ra4951]

I have written a gdb stub for mcore-elf, and in my efforts to improve it I have noticed that gdb defines too many control registers for the mcore chip.  Despite having a 5-bit field in the control register move instructions, there are not actually 32 control registers on the mcore.  All the existing mcore designs, either current or planned, have only 13 control registers.  The gdb source code defines all 32, but  cr13..cr31 don't actually exist.

It speeds up the stub not to have to report the status of these phantom registers over the serial line.  Patching them out of gdb also allows the stub to keep its RAM requirement below 1K.

My question is, would it be advisable to make this change to the gdb mainline?  I realize that there will always be unintended consequences of such a patch.  Any thoughts?

Regards,
--
Brian LaPonsey
Motorola Semiconductor

Re: mcore registers

[Andrew Cagney]

> I have written a gdb stub for mcore-elf, and in my efforts to improve it I have noticed that gdb defines too many control registers for the mcore chip.  Despite having a 5-bit field in the control register move instructions, there are not actually 32 control registers on the mcore.  All the existing mcore designs, either current or planned, have only 13 control registers.  The gdb source code defines all 32, but  cr13..cr31 don't actually exist.
> 
> It speeds up the stub not to have to report the status of these phantom registers over the serial line.  Patching them out of gdb also allows the stub to keep its RAM requirement below 1K.
> 
> My question is, would it be advisable to make this change to the gdb mainline?  I realize that there will always be unintended consequences of such a patch.  Any thoughts?

Can you post the output from "maint print registers"?  If these 
registers are last, the stub can send back a short register packet (such 
a packet implies that remaining registers are zero, gdb shouldn't send a 
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.

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

Andrew