From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 95930 invoked by alias); 11 Jun 2015 08:56:54 -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 95896 invoked by uid 89); 11 Jun 2015 08:56:53 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-pd0-f169.google.com Received: from mail-pd0-f169.google.com (HELO mail-pd0-f169.google.com) (209.85.192.169) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 11 Jun 2015 08:56:52 +0000 Received: by pdjm12 with SMTP id m12so544994pdj.3 for ; Thu, 11 Jun 2015 01:56:50 -0700 (PDT) X-Received: by 10.66.242.79 with SMTP id wo15mr13429139pac.6.1434013010402; Thu, 11 Jun 2015 01:56:50 -0700 (PDT) Received: from [127.0.0.1] (gcc1-power7.osuosl.org. [140.211.15.137]) by mx.google.com with ESMTPSA id rt8sm34038pbb.37.2015.06.11.01.56.48 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Jun 2015 01:56:49 -0700 (PDT) Message-ID: <55794D4A.1090009@gmail.com> Date: Thu, 11 Jun 2015 08:56:00 -0000 From: Yao Qi User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Vladimir Prus , gdb-patches@sourceware.org Subject: Re: [WIP] Bare-metal register browsing References: <55349CDB.8010100@codesourcery.com> <864mo5yi1x.fsf@gmail.com> <553E7F2D.6000707@gmail.com> <86lhg2nu3x.fsf@gmail.com> <86h9qno7xo.fsf@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2015-06/txt/msg00204.txt.bz2 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. > > 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? Yes, that is what I want to suggest too. -- Yao (齐尧)