From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29587 invoked by alias); 9 Jun 2015 20:50:04 -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 29578 invoked by uid 89); 9 Jun 2015 20:50:03 -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; Tue, 09 Jun 2015 20:50:02 +0000 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Z2QSy-0003Qp-OH for gdb-patches@sourceware.org; Tue, 09 Jun 2015 22:49:48 +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 ; Tue, 09 Jun 2015 22:49:48 +0200 Received: from vladimir.prus by h86-62-88-129.ln.rinet.ru with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 09 Jun 2015 22:49:48 +0200 To: gdb-patches@sourceware.org From: Vladimir Prus Subject: Re: [WIP] Bare-metal register browsing Date: Tue, 09 Jun 2015 20:50: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> 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: <86h9qno7xo.fsf@gmail.com> X-IsSubscribed: yes X-SW-Source: 2015-06/txt/msg00159.txt.bz2 Yao, On 6/4/2015 5:38 PM, Yao Qi wrote: > Vladimir Prus writes: > >> 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? > > That is fine to me, but I am not sure the meaning of > target-object="memory" here? Does this mean this group of registers are > mapped to memory? 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. > 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. May I suggest we start from a simple use case, where an alternative access mechanism can only be specified for a top-level group, and it's explicitly specified by target-object attribute? Should the need arise for mixing differently-accessed registers inside one group, that can be implemented later with extra code. >> 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 don't have preference here. > >> >> - 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? > > You have to explain the meaning of target-object and annex first and > what are the possible values of them. > > My last concern is about the testing of these new things in target > description. We need some test cases that people can run in their own > dev env, without involving setting up OpenOCD/JTAG probe/embedded boards. That's a valid concern. I was using a particular board with USB interface, so did not need a probe, but even that is not trivial to setup or automate. If we were to test on a regular computer, I suppose the only way is to have some variables in a C program, determine their addresses after debug session start, and generate target XML dynamically from that? - Volodya