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: Wed, 23 Jan 2013 13:28:54 +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 <50FEAAB2.9090903@redhat.com> <C6CA53A2A46BA7469348BDBD663AB65848578991@KCHJEXMB02.kpit.com>
On 01/23/2013 12:50 PM, Kaushik Phatak wrote:
>> You mean additional code in gdbserver, or in the kernel? I'd think the
>> former.
> Yes, the code changes would be for gdbserver and gdb.
> I would prefer to keep my kernel code changes to a minimal.
>
>> 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.
> Yes, I agree. Disturbing the .dat file is causing issues in the
> remote protocol.
What issues? Can you be more specific?
> So, using pseudo registers within gdb would be a
> better way to proceed as long as I can get the register numbers to
> match my expedite register numbers.
--
Pedro Alves