From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26104 invoked by alias); 23 Jan 2013 14:04:20 -0000 Received: (qmail 26080 invoked by uid 22791); 23 Jan 2013 14:04:19 -0000 X-SWARE-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_NO,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from co9ehsobe004.messaging.microsoft.com (HELO co9outboundpool.messaging.microsoft.com) (207.46.163.27) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 23 Jan 2013 14:04:12 +0000 Received: from mail1-co9-R.bigfish.com (10.236.132.249) by CO9EHSOBE007.bigfish.com (10.236.130.70) with Microsoft SMTP Server id 14.1.225.23; Wed, 23 Jan 2013 14:04:11 +0000 Received: from mail1-co9 (localhost [127.0.0.1]) by mail1-co9-R.bigfish.com (Postfix) with ESMTP id 84C734C05CC; Wed, 23 Jan 2013 14:04:11 +0000 (UTC) X-Forefront-Antispam-Report: CIP:59.163.77.177;KIP:(null);UIP:(null);IPV:NLI;H:KCHJEXHC02.kpit.com;RD:59.163.77.177.static.vsnl.net.in;EFVD:NLI X-SpamScore: 0 X-BigFish: VPS0(zzd6eahzz1ee6h1de0h1202h1e76h1d1ah1d2ahzzz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h14ddh1504h1537h153bh15d0h162dh1631h1758h18e1h1155h) Received: from mail1-co9 (localhost.localdomain [127.0.0.1]) by mail1-co9 (MessageSwitch) id 1358949850164343_16043; Wed, 23 Jan 2013 14:04:10 +0000 (UTC) Received: from CO9EHSMHS015.bigfish.com (unknown [10.236.132.243]) by mail1-co9.bigfish.com (Postfix) with ESMTP id 22EE0260063; Wed, 23 Jan 2013 14:04:10 +0000 (UTC) Received: from KCHJEXHC02.kpit.com (59.163.77.177) by CO9EHSMHS015.bigfish.com (10.236.130.25) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 23 Jan 2013 14:04:07 +0000 Received: from KCHJEXMB02.kpit.com ([169.254.2.51]) by KCHJEXHC02.kpit.com ([172.10.15.74]) with mapi id 14.02.0247.003; Wed, 23 Jan 2013 19:34:04 +0530 From: Kaushik Phatak To: Pedro Alves CC: "gdb-patches@sourceware.org" Subject: RE: [RFA 4/5] New port: CR16: gdbserver Date: Wed, 23 Jan 2013 14:04:00 -0000 Message-ID: References: <50CB742E.9090506@redhat.com> <50F97ABF.4060203@redhat.com> <50FFE596.20303@redhat.com> In-Reply-To: <50FFE596.20303@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: 2013-01/txt/msg00549.txt.bz2 >> Yes, I agree. Disturbing the .dat file is causing issues in the=20 >> remote protocol.=20 >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=20 to 21 which is way above what my kernel can handle causing it to error out. I could add special to handle this at kernel, but it will slow it down quite a bit. Additionally, the ptrace in kernel gets its data from a 'get_reg' function which accepts specific regnums and it will tricky to disturb this. =20 Regards, Kaushik