From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32142 invoked by alias); 23 Jan 2013 12:50:50 -0000 Received: (qmail 32130 invoked by uid 22791); 23 Jan 2013 12:50:49 -0000 X-SWARE-Spam-Status: No, hits=-4.7 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 co9ehsobe005.messaging.microsoft.com (HELO co9outboundpool.messaging.microsoft.com) (207.46.163.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 23 Jan 2013 12:50:41 +0000 Received: from mail70-co9-R.bigfish.com (10.236.132.253) by CO9EHSOBE007.bigfish.com (10.236.130.70) with Microsoft SMTP Server id 14.1.225.23; Wed, 23 Jan 2013 12:50:41 +0000 Received: from mail70-co9 (localhost [127.0.0.1]) by mail70-co9-R.bigfish.com (Postfix) with ESMTP id 0B63DA03ED; Wed, 23 Jan 2013 12:50:41 +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: -1 X-BigFish: VPS-1(zz4015Izz1ee6h1de0h1202h1e76h1d1ah1d2ahzzz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h14ddh1504h1537h153bh15d0h162dh1631h1758h18e1h1155h) Received: from mail70-co9 (localhost.localdomain [127.0.0.1]) by mail70-co9 (MessageSwitch) id 135894543933280_29089; Wed, 23 Jan 2013 12:50:39 +0000 (UTC) Received: from CO9EHSMHS004.bigfish.com (unknown [10.236.132.240]) by mail70-co9.bigfish.com (Postfix) with ESMTP id 05BDF340078; Wed, 23 Jan 2013 12:50:39 +0000 (UTC) Received: from KCHJEXHC02.kpit.com (59.163.77.177) by CO9EHSMHS004.bigfish.com (10.236.130.14) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 23 Jan 2013 12:50:38 +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 18:20:32 +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 12:50:00 -0000 Message-ID: References: <50CB742E.9090506@redhat.com> <50F97ABF.4060203@redhat.com> In-Reply-To: <50FEAAB2.9090903@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/msg00545.txt.bz2 > 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.=20 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=20 remote protocol. So, using pseudo registers within gdb would be a=20 better way to proceed as long as I can get the register numbers to=20 match my expedite register numbers. Thanks, Kaushik