From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 84870 invoked by alias); 27 Apr 2015 18:25:53 -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 84861 invoked by uid 89); 27 Apr 2015 18:25:52 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,SPF_SOFTFAIL autolearn=no version=3.3.2 X-HELO: mail.lvk.cs.msu.su Received: from gate.lvk.cs.msu.su (HELO mail.lvk.cs.msu.su) (158.250.17.1) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 27 Apr 2015 18:25:50 +0000 Received: from mail.lvk.cs.msu.su (localhost.localdomain [127.0.0.1]) by mail.lvk.cs.msu.su (Postfix) with ESMTP id 780AE70193A; Mon, 27 Apr 2015 21:25:43 +0300 (MSK) X-Spam-ASN: Received: from [192.168.0.115] (h86-62-88-129.ln.rinet.ru [86.62.88.129]) by mail.lvk.cs.msu.su (Postfix) with ESMTPSA id 5A9EB700FE3; Mon, 27 Apr 2015 21:25:38 +0300 (MSK) Message-ID: <553E7F2D.6000707@gmail.com> Date: Mon, 27 Apr 2015 18:25:00 -0000 From: Vladimir Prus User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 Newsgroups: gmane.comp.gdb.patches To: Yao Qi , Vladimir Prus CC: "gdb-patches@sourceware.org" Subject: Re: [WIP] Bare-metal register browsing References: <55349CDB.8010100@codesourcery.com> <864mo5yi1x.fsf@gmail.com> In-Reply-To: <864mo5yi1x.fsf@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-AV-Checked: ClamAV using ClamSMTP X-SW-Source: 2015-04/txt/msg01007.txt.bz2 On 04/24/2015 12:47 PM, Yao Qi wrote:> Vladimir Prus writes: > > Hi Vladimir, > >> The attached patches implement accessing peripheral registers on >> bare-metal targets. Typically, >> these registers are memory-mapped, so one can poke at them using >> memory operations, but it's >> far from convenient. Also, on some targets the registers might require >> a custom way of access, >> which makes things even less convenient. >> >> This patch allows target XML to describe 'spaces' - contains of >> registers, which can be further grouped. >> Given that descrpiption, GDB allows one to do something like: >> >> (gdb) print $io.GPIO_PORTF.GPIO_PORTFDIR >> $7 = -1 >> >> to access registers. One can also do >> >> (gdb) ptype $io >> >> to see top-level register groups in space 'io', and so find the >> desired register. > > What does the xml using 'spaces' look like? A small example would be > useful. Target description "reg" has already had a component "type", > can't we extend "type" for memory-mapped registers? I am trying to > understand how useful it is to add 'spaces' here. Hi Yao, Here's extract from an actual file size="32" name="UART3CTL" offset="0x4000f030" read-sensitive="no" save-restore="yes" type="UART0_UART0CTL"/> The full file can be found at https://drive.google.com/open?id=0BzXbGnw_jIF6cThVZHU2T3l0SXM&authuser=0 The space and group elements are not 100% required - it might be possible to instead have something like: But it seems to me that this overloading of existing concepts might not be perfect: - Normally, top level 'reg' element are accessed using ordinary packets, so we'd need to special case 'reg' above - Using 'reg' element to refer to large number of registers, and using 'field' to refer to registers can be confusing. - GDB type system does not support 'offset' field for physical address, and unlike space, there is no easy place to add this information. So it seems to me that the original syntax is more straight-forward representation of hardware. Thanks, Volodya -- Vladimir Prus CodeSourcery / Mentor Embedded http://vladimirprus.com -- Vladimir Prus CodeSourcery / Mentor Embedded http://vladimirprus.com From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 85600 invoked by alias); 27 Apr 2015 18:26:01 -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 85582 invoked by uid 89); 27 Apr 2015 18:26:00 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 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; Mon, 27 Apr 2015 18:25:58 +0000 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Ymnj6-0007RV-UT for gdb-patches@sourceware.org; Mon, 27 Apr 2015 20:25:52 +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 ; Mon, 27 Apr 2015 20:25:52 +0200 Received: from vladimir.prus by h86-62-88-129.ln.rinet.ru with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 27 Apr 2015 20:25:52 +0200 To: gdb-patches@sourceware.org From: Vladimir Prus Subject: Re: [WIP] Bare-metal register browsing Date: Mon, 27 Apr 2015 18:39:00 -0000 Message-ID: <553E7F2D.6000707@gmail.com> References: <55349CDB.8010100@codesourcery.com> <864mo5yi1x.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "gdb-patches@sourceware.org" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 In-Reply-To: <864mo5yi1x.fsf@gmail.com> X-IsSubscribed: yes X-SW-Source: 2015-04/txt/msg01008.txt.bz2 Message-ID: <20150427183900.QAaI4Ll1KUIPLrMM-wtdFwljZAjG82b3NHl7DzXPGpk@z> On 04/24/2015 12:47 PM, Yao Qi wrote:> Vladimir Prus writes: > > Hi Vladimir, > >> The attached patches implement accessing peripheral registers on >> bare-metal targets. Typically, >> these registers are memory-mapped, so one can poke at them using >> memory operations, but it's >> far from convenient. Also, on some targets the registers might require >> a custom way of access, >> which makes things even less convenient. >> >> This patch allows target XML to describe 'spaces' - contains of >> registers, which can be further grouped. >> Given that descrpiption, GDB allows one to do something like: >> >> (gdb) print $io.GPIO_PORTF.GPIO_PORTFDIR >> $7 = -1 >> >> to access registers. One can also do >> >> (gdb) ptype $io >> >> to see top-level register groups in space 'io', and so find the >> desired register. > > What does the xml using 'spaces' look like? A small example would be > useful. Target description "reg" has already had a component "type", > can't we extend "type" for memory-mapped registers? I am trying to > understand how useful it is to add 'spaces' here. Hi Yao, Here's extract from an actual file size="32" name="UART3CTL" offset="0x4000f030" read-sensitive="no" save-restore="yes" type="UART0_UART0CTL"/> The full file can be found at https://drive.google.com/open?id=0BzXbGnw_jIF6cThVZHU2T3l0SXM&authuser=0 The space and group elements are not 100% required - it might be possible to instead have something like: But it seems to me that this overloading of existing concepts might not be perfect: - Normally, top level 'reg' element are accessed using ordinary packets, so we'd need to special case 'reg' above - Using 'reg' element to refer to large number of registers, and using 'field' to refer to registers can be confusing. - GDB type system does not support 'offset' field for physical address, and unlike space, there is no easy place to add this information. So it seems to me that the original syntax is more straight-forward representation of hardware. Thanks, Volodya -- Vladimir Prus CodeSourcery / Mentor Embedded http://vladimirprus.com -- Vladimir Prus CodeSourcery / Mentor Embedded http://vladimirprus.com