Re: [RFA 4/5] New port: CR16: gdbserver

[Pedro Alves <palves@redhat.com>]

On 01/23/2013 02:04 PM, Kaushik Phatak wrote:
>>> Yes, I agree. Disturbing the .dat file is causing issues in the 
>>> remote protocol. 
>> What issues?  Can you be more specific?
> 
> The kernel defines only 15 registers, r0 to r11 as pairs, (total 6) then
> the other 9 32-bit registers r12, r13 and special registers ra,pc,usp,psr,
> pad,intbase, and r0r1_orig.
> If I want the .dat to match the register numbers in gdb, then my .dat would
> look like this,
> {{{
> name:cr16
> expedite:psr,pc,usp
> 16:r0
> 16:r1
> 16:r2
> 16:r3
> 16:r4
> 16:r5
> 16:r6
> 16:r7
> 16:r8
> 16:r9
> 16:r10
> 16:r11
> 32:r12
> 32:r13
> 32:ra
> 32:psr
> 32:pc
> 32:r0r1_orig
> 32:intbase
> 32:usp
> 32:cfg
> }}}
> 
> This is consistent with gdb. However, this way my register count goes 
> to 21 which is way above what my kernel can handle causing
> it to error out. 

This is not an issue with the remote protocol.  It's just an issue of
cr16 gdbserver implementation.
So you'd decouple the remote protocol register numbers from the
ptrace numbers in gdbserver.  The .dat file is about gdbserver's
register cache, which maps the RSP numbering.  IOW, nothing prevents
make gdbserver map the RSP numbering to ptrace numbering when
marshalling things to/from ptrace.  This is what cr16_regmap is about
afterall, except that you have the register pairs peculiarity, which
may need more code to support.  I was suspecting this confusion,
thus my prod.  ;-)

> I could add special to handle this at kernel, but it
> will slow it down quite a bit. 

I don't think any single ptrace call would be slowed down
by any significant amount.  It's the fact that you'd
require double the ptrace calls that could add up.  In any
case, the right fix for that is PTRACE_GETREGS.  I'd hope new
kernel ports wouldn't go upstream without that nowadays, though...

A keep-backward-compatibility-with-whats-in-the-field-already
card would be a better play here.
What style of RSP register numbering do bare metal stubs running
on cr16 use?  Do they also do the register pairing trick?

I don't really care whether the pairs end up in the RSP or
not.  If you prefer that path, it's okay with me, provided
RSP numbering ends up correctly decoupled on the GDB side.

-- 
Pedro Alves