This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA 4/5] New port: CR16: gdbserver
- From: Pedro Alves <palves at redhat dot com>
- To: Kaushik Phatak <Kaushik dot Phatak at kpitcummins dot com>
- Cc: "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Tue, 22 Jan 2013 15:05:22 +0000
- Subject: Re: [RFA 4/5] New port: CR16: gdbserver
- References: <C6CA53A2A46BA7469348BDBD663AB65845B2FF84@KCHJEXMB03.kpit.com> <50CB742E.9090506@redhat.com> <C6CA53A2A46BA7469348BDBD663AB65848564536@KCHJEXMB02.kpit.com> <50F97ABF.4060203@redhat.com> <C6CA53A2A46BA7469348BDBD663AB65848577553@KCHJEXMB02.kpit.com>
On 01/22/2013 01:42 PM, Kaushik Phatak wrote:
> Hi Pedro,
> Thanks for your feedback.
>
>> No, this needs to be fixed. The .dat registers must agree with GDB's remote
>> register set. Once that is fixed, you'll be able to put more registers
>> in the "expedite" set
>
> I am working on these points. From what I see, my cr16_regmap needs to be
> 4-byte aligned so that ptrace calls within linux-low.c can use these without
> causing any I/O errors. The updated reg.dat file would not match in offset
> to cr16_regmap, but would match gdb.
> Some additional code would be needed to handle the padding and packing through
> ptrace in the kernel.
You mean additional code in gdbserver, or in the kernel? I'd think the
former.
> This would allow the correct register number to be
> accessed which would match gdb as well as reg-cr16.dat.
> Let me know if you have any thoughts on this.
The alternative would be to go all the other way around
-- always expose the registers as pairs in the remote protocol,
and then implement the user visible non-paired registers in
GDB as pseudo registers (and hide the pairs). IOW, your .dat
file would stay the same, and gdbserver wouldn't change. GDB's
core cr16 register numbers would be decoupled from the RSP
register set. It sounds a little uglier to me though.
--
Pedro Alves