From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11347 invoked by alias); 5 Jan 2015 11:40:09 -0000 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 Received: (qmail 11333 invoked by uid 89); 5 Jan 2015 11:40:07 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 05 Jan 2015 11:40:05 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t05Be2Xj031725 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 5 Jan 2015 06:40:02 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t05BdxQp022122; Mon, 5 Jan 2015 06:40:00 -0500 Message-ID: <54AA780E.6080106@redhat.com> Date: Mon, 05 Jan 2015 11:40:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: Yao Qi , gdb-patches@sourceware.org Subject: Re: [PATCH] MIPS: Handle the DSP registers for bare metal References: <1418909149-29929-1-git-send-email-yao@codesourcery.com> <54930ED2.1080806@redhat.com> <87r3vwqooq.fsf@codesourcery.com> <5494098B.7080002@redhat.com> <54A27A7E.4070200@redhat.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-01/txt/msg00044.txt.bz2 On 12/30/2014 12:10 PM, Maciej W. Rozycki wrote: > On Tue, 30 Dec 2014, Pedro Alves wrote: > >>> > > I'm not sure offhand whether the piece of patch proposed you refer to >>> > > here is correct or not, but the overall scope of this and the other patch >>> > > Yao has mentioned yet outstanding is support for legacy bare-metal RSP >>> > > stubs that have no notion of target descriptions and may even predate >>> > > GDB's support for these descriptions, and yet they want to make all >>> > > processor registers available for inspection and modification by GDB. >>> > > This code comes from MIPS UK and dates back to early 2000s and I think it >>> > > would be good having it upstream so that standard GDB can talk to these >>> > > stubs. The fixed layout of the g/G packet and corresponding p/P packet >>> > > offsets have been set by the bare-metal SDE toolchain years ago. >> > >> > The way to handle that is still through target descriptions -- if a >> > target doesn't send a target description, GDB maps known layouts to built-in >> > target descriptions. See mips_register_g_packet_guesses. > Register probing Yao mentioned is still needed, because in this fixed > packet format the whole set of architecturally defined register slots is > exchanged with the RSP stub, e.g. 8 * 32 = 256 CP0 registers, 8 * 32 = 256 > CP2 registers, etc. (as documented by the change to mips-tdep.h proposed), > even if some are not present, e.g. not all CP0 register slots have already > been allocated in the architecture so far and the vast majority of them is > optional. That's orthogonal. > > The information on which registers are present and which are not will not > be supplied by the target and has to be determined by gradual discovery, > that is poking at registers as they are determined to be present, i.e. > first CP0.PRId that is always there, then CP0.Config0 if present, then > CP0.Config1 if present, and so on. Gaps will be present in the packets > exchanged for the absent registers as with the ACX registers discussed > previously. > > And if we were to define built-in target descriptions for the possible > variants of present register sets, then, as noted by Yao, we hit the issue > of having to make some 2^50 templates (slightly fewer actually, as there That'd be silly of course, but it's also not what I meant. The built-in description is used for the case of a legacy stubs that does not report a target description, and those stubs you say use a fixed register layout. So we're talking about _one_ built-in target description that describes that fixed register layout. > are some dependencies between the presence of some registers, e.g. you > can't have a processor that has a CP0.Config2 register, but does not have > CP0.Config1, the reverse is allowed; similarly a CPU can't have the ACX > register when it does not have CP0.Config3) which is of course beyond > technical capabilities as e.g. a 32-bit host will have fewer bytes of > addressable memory even. > NB `mips_register_g_packet_guesses' is not necessarily relevant here as > there may be registers accessible through the stub via the p/P packets > only and not included in the g/G packet layout for performance reasons If existing/legacy stubs are doing that in practice, then we can make gdb pick the fallback description (in case in target doesn't provide one) depending on selected osabi. > (the packet may be shorter than the maximum defined) as to transfer all > the registers through a JTAG link every time the target is stopped may be > exceedingly slow, especially when single-stepping. For the single-stepping case, the fix should be to include all the registers GDB needs to compute whether the step finished directly in the expedite stop reply, though. Thanks, Pedro Alves