From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12984 invoked by alias); 28 Dec 2012 04:42:06 -0000 Received: (qmail 12971 invoked by uid 22791); 28 Dec 2012 04:42:03 -0000 X-SWARE-Spam-Status: No, hits=-5.0 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_NO,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,TW_EG X-Spam-Check-By: sourceware.org Received: from co1ehsobe004.messaging.microsoft.com (HELO co1outboundpool.messaging.microsoft.com) (216.32.180.187) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 28 Dec 2012 04:41:54 +0000 Received: from mail132-co1-R.bigfish.com (10.243.78.215) by CO1EHSOBE007.bigfish.com (10.243.66.70) with Microsoft SMTP Server id 14.1.225.23; Fri, 28 Dec 2012 04:41:53 +0000 Received: from mail132-co1 (localhost [127.0.0.1]) by mail132-co1-R.bigfish.com (Postfix) with ESMTP id 1732A1201A3; Fri, 28 Dec 2012 04:41:53 +0000 (UTC) X-Forefront-Antispam-Report: CIP:59.163.77.45;KIP:(null);UIP:(null);IPV:NLI;H:KCHJEXHC01.kpit.com;RD:59.163.77.45.static.vsnl.net.in;EFVD:NLI X-SpamScore: -4 X-BigFish: VPS-4(zz168aJ1102I1447Izz1de0h1202h1e76h1d1ah1d2ahzzz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h14ddh1504h1537h153bh15d0h162dh1631h1758h1155h) Received: from mail132-co1 (localhost.localdomain [127.0.0.1]) by mail132-co1 (MessageSwitch) id 1356669711673636_29313; Fri, 28 Dec 2012 04:41:51 +0000 (UTC) Received: from CO1EHSMHS024.bigfish.com (unknown [10.243.78.220]) by mail132-co1.bigfish.com (Postfix) with ESMTP id 986F0AC004A; Fri, 28 Dec 2012 04:41:51 +0000 (UTC) Received: from KCHJEXHC01.kpit.com (59.163.77.45) by CO1EHSMHS024.bigfish.com (10.243.66.34) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 28 Dec 2012 04:41:51 +0000 Received: from KCHJEXMB02.kpit.com ([169.254.2.126]) by KCHJEXHC01.kpit.com ([172.10.15.73]) with mapi id 14.02.0247.003; Fri, 28 Dec 2012 10:11:48 +0530 From: Kaushik Phatak To: Pedro Alves CC: "gdb-patches@sourceware.org" Subject: RE: [RFA 4/5] New port: CR16: gdbserver Date: Fri, 28 Dec 2012 04:42:00 -0000 Message-ID: References: <50CB742E.9090506@redhat.com> In-Reply-To: <50CB742E.9090506@redhat.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: kpitcummins.com Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-12/txt/msg00832.txt.bz2 Hi Pedro, Thanks for the detailed review. I will take care of all the formatting and re-base this with GDB mainline w= hen I resubmit the patch. To answer some of your points, > +cr16_supply_ptrace_register (struct regcache *regcache, > Is the shift visible in GDB or not? Is this a ptrace quirk, > or an architecture quirk? If the latter, why isn't GDB itself, and > the cr16_set_pc cr16_get_pc routines in gdbserver handling this? This is an architecture quirk as the PC is 24 bits wide and only top 23 bits can be read. The last bit is always zero, so user has to left shift to get the correct value. The 'supply_ptrace_register' seemed like the correct pla= ce to make these manipulations similar to s390 or the ppc ports. Manipulations in the get_pc and set_pc calls did not seem to get the=20 desired effect while reading PC from the target. > +32:r10and11 > Eh. What's the rationale for this? Peeking at the GDB patch, I saw no > pseudo registers support. This is the way the kernel port defines the PT_REGS structure. This allows = for faster access as register pair move reg_names (movd rp,rp) instruction is=20 supported. However, we needed individual registers to be viewed under gdb. > +expedite:psr > Why only psr? That's surprising. In case I add any other registers, then the offset of that register is=20 incorrect with respect to the "reg_names", and the size does not match=20 which is returned by "cr16_register_type". For example, if I add=20 expedite:psr,ra Then 'ra' is register number 8, and has size 32 bits as per reg-cr16.dat,=20 however,for number 8, I have r8 in "reg_names" (cr16-tdep.c) which has=20 size 16 bits. When gdb requests for the expedite registers, it gets data and throws error, "Badly formatted packet" -> I guess this is expected, as it returns 32 bits for 'ra' as per reg-cr16.dat, but it expects only 16 bits for 'r8'. I know this is bit of a hack, however to get the gdbserver running on the kernel and keeping it in sync with the host, this seemed my best bet. >> + (*the_target->read_memory) (where, (unsigned char *) &insn, >> + cr16_breakpoint_len); > Most ports fail to do this, but the above may fail. That should be > checked here. I have probably borrowed this from cris port. Do I need to perform addition= al here? Please let me know if there is any other port I can refer to. Please let me know if the above justifications are ok. Thanks & Best Regards, Kaushik