From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4935 invoked by alias); 22 Jan 2013 15:05:43 -0000 Received: (qmail 4916 invoked by uid 22791); 22 Jan 2013 15:05:41 -0000 X-SWARE-Spam-Status: No, hits=-7.7 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 22 Jan 2013 15:05:26 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r0MF5OdX000812 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 22 Jan 2013 10:05:24 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r0MF5MjF004239; Tue, 22 Jan 2013 10:05:23 -0500 Message-ID: <50FEAAB2.9090903@redhat.com> Date: Tue, 22 Jan 2013 15:05:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: Kaushik Phatak CC: "gdb-patches@sourceware.org" Subject: Re: [RFA 4/5] New port: CR16: gdbserver References: <50CB742E.9090506@redhat.com> <50F97ABF.4060203@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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/msg00527.txt.bz2 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