From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6175 invoked by alias); 15 Jun 2015 13:51:32 -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 6166 invoked by uid 89); 15 Jun 2015 13:51:31 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=BAYES_00,FREEMAIL_FROM,FSL_HELO_BARE_IP_2,RCVD_IN_DNSWL_LOW,RCVD_NUMERIC_HELO,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.3.2 X-HELO: plane.gmane.org Received: from plane.gmane.org (HELO plane.gmane.org) (80.91.229.3) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Mon, 15 Jun 2015 13:51:29 +0000 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Z4UnO-00059Z-NL for gdb-patches@sourceware.org; Mon, 15 Jun 2015 15:51:26 +0200 Received: from 195.239.242.70 ([195.239.242.70]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 15 Jun 2015 15:51:26 +0200 Received: from vladimir.prus by 195.239.242.70 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 15 Jun 2015 15:51:26 +0200 To: gdb-patches@sourceware.org From: Vladimir Prus Subject: Re: [WIP] Bare-metal register browsing Date: Mon, 15 Jun 2015 13:51:00 -0000 Message-ID: References: <55349CDB.8010100@codesourcery.com> <864mo5yi1x.fsf@gmail.com> <553E7F2D.6000707@gmail.com> <86lhg2nu3x.fsf@gmail.com> <86h9qno7xo.fsf@gmail.com> <55794D4A.1090009@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 In-Reply-To: <55794D4A.1090009@gmail.com> X-IsSubscribed: yes X-SW-Source: 2015-06/txt/msg00306.txt.bz2 On 6/11/2015 11:56 AM, Yao Qi wrote: > On 09/06/15 21:49, Vladimir Prus wrote: >> It's a bit more generic - it means that to obtain values of any register >> in this group, GDB should perform qXfer of the specified target object >> and annex, using register's offset. Memory is the most typical target >> object, >> but in our case, we had other sorts of registers, so I'd prefer the >> design to >> not lock us into memory-mapped registers. >> > > I don't object to it. > >>> Does "offset=0x4000e030" mean this register is mapped >>> at address 0x4000e030? If the answers of both questions are yes, is >>> target-object="memory" still necessary? Without it, we can still define >>> a group of memory-mapped registers like: >>> >>> >>> >>> >>> >>> >>> >>> and we may even can define a group of normal registers and memory-mapped >>> registers, (even it is not likely in practise) >>> >>> >>> >>> >>> >>> >>> >>> In this case, UART1_1 and UART1_2 are memory-mapped, while UART1_3 is >>> not. IMO, memory-map-ness is an attribute of each register instead of a >>> group, so better to define such attribute on each register level. >> >> It is possible in theory, but I think it has two drawbacks. >> >> First, I think specifying target object is more explicit (and therefore >> better >> than implicit, especially for machine-oriented format) and more generic, >> as it allows >> us to use other target objects. >> >> Second, implementing such mixed registers group is extra complexity, and >> we did >> not find any need for that in practice. > > If such mixed registers group brings extra complexity in the > implementation, then I am inclined to start from a simple one. Yes, I think it brings extra complexity. Thanks for your comments; I plan to update the patch to: - Use top-level group for register browsing, as opposed to element - Do some form of testing that does not require hardware. Thanks, Volodya