From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 67862 invoked by alias); 3 Jun 2015 19:49:21 -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 67846 invoked by uid 89); 3 Jun 2015 19:49:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham 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; Wed, 03 Jun 2015 19:49:19 +0000 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Z0Eev-0005Ui-5h for gdb-patches@sourceware.org; Wed, 03 Jun 2015 21:49:05 +0200 Received: from h86-62-88-129.ln.rinet.ru ([86.62.88.129]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 03 Jun 2015 21:49:05 +0200 Received: from vladimir.prus by h86-62-88-129.ln.rinet.ru with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 03 Jun 2015 21:49:05 +0200 To: gdb-patches@sourceware.org From: Vladimir Prus Subject: Re: [WIP] Bare-metal register browsing Date: Wed, 03 Jun 2015 19:49:00 -0000 Message-ID: References: <55349CDB.8010100@codesourcery.com> <864mo5yi1x.fsf@gmail.com> <553E7F2D.6000707@gmail.com> <86lhg2nu3x.fsf@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: <86lhg2nu3x.fsf@gmail.com> X-IsSubscribed: yes X-SW-Source: 2015-06/txt/msg00059.txt.bz2 On 6/2/2015 4:00 PM, Yao Qi wrote: > Vladimir Prus writes: > >> >> >> >> >> >> >> size="32" name="UART3CTL" offset="0x4000f030" read-sensitive="no" save-restore="yes" type="UART0_UART0CTL"/> >> >> > > It is good to have a "group" element, so that we can easily define a > group of registers. However, what is the usefulness of element "space"? > to define a group of "group" elements? The original motivation was to indicate that particular set of registers are not usual registers, and must be accessed in a different way. It's not strictly necessary, we can rewrite the above as: Maybe my patch can be modified to not introduce a new target object, after all. We can use: to describe memory-mapped io registers. It sounds like this should be possible to implement. What do you think? Two questions: - Is 'group' ok, or 'register-group' would be more clear? We found that the size of these XML files can be sometimes a problem - I'd propose that 'target-object' and 'annex' attribute are only allowed for top-level 'group' element, and not for top-level 'reg' or nested 'group' element, to make implementation simpler. Is that fine? Thanks, Volodya