From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26830 invoked by alias); 23 Jan 2013 14:44:09 -0000 Received: (qmail 26792 invoked by uid 22791); 23 Jan 2013 14:44:08 -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; Wed, 23 Jan 2013 14:44:03 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r0NEi2lj027101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 23 Jan 2013 09:44:02 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r0NEi0xH024682; Wed, 23 Jan 2013 09:44:01 -0500 Message-ID: <50FFF730.9050108@redhat.com> Date: Wed, 23 Jan 2013 14:44: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> <50FFE596.20303@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/msg00552.txt.bz2 On 01/23/2013 02:04 PM, Kaushik Phatak wrote: >>> Yes, I agree. Disturbing the .dat file is causing issues in the >>> remote protocol. >> 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 > to 21 which is way above what my kernel can handle causing > it to error out. This is not an issue with the remote protocol. It's just an issue of cr16 gdbserver implementation. So you'd decouple the remote protocol register numbers from the ptrace numbers in gdbserver. The .dat file is about gdbserver's register cache, which maps the RSP numbering. IOW, nothing prevents make gdbserver map the RSP numbering to ptrace numbering when marshalling things to/from ptrace. This is what cr16_regmap is about afterall, except that you have the register pairs peculiarity, which may need more code to support. I was suspecting this confusion, thus my prod. ;-) > I could add special to handle this at kernel, but it > will slow it down quite a bit. I don't think any single ptrace call would be slowed down by any significant amount. It's the fact that you'd require double the ptrace calls that could add up. In any case, the right fix for that is PTRACE_GETREGS. I'd hope new kernel ports wouldn't go upstream without that nowadays, though... A keep-backward-compatibility-with-whats-in-the-field-already card would be a better play here. What style of RSP register numbering do bare metal stubs running on cr16 use? Do they also do the register pairing trick? I don't really care whether the pairs end up in the RSP or not. If you prefer that path, it's okay with me, provided RSP numbering ends up correctly decoupled on the GDB side. -- Pedro Alves