From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8661 invoked by alias); 6 Dec 2006 09:25:14 -0000 Received: (qmail 8651 invoked by uid 22791); 6 Dec 2006 09:25:13 -0000 X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 06 Dec 2006 09:25:07 +0000 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1Grt1S-0000U1-6O for gdb-patches@sources.redhat.com; Wed, 06 Dec 2006 10:25:02 +0100 Received: from 73-198.umostel.ru ([82.179.73.198]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 06 Dec 2006 10:25:02 +0100 Received: from ghost by 73-198.umostel.ru with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 06 Dec 2006 10:25:02 +0100 To: gdb-patches@sources.redhat.com From: Vladimir Prus Subject: Re: variable objects and registers Date: Wed, 06 Dec 2006 09:25:00 -0000 Message-ID: References: <200611292020.47109.vladimir@codesourcery.com> <20061205211607.GB28333@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit User-Agent: KNode/0.10.2 X-IsSubscribed: yes 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 X-SW-Source: 2006-12/txt/msg00062.txt.bz2 Daniel Jacobowitz wrote: > On Wed, Nov 29, 2006 at 08:20:47PM +0300, Vladimir Prus wrote: >> >> I was working on implementing a new MI command that creates variable >> objects for registers, and I have something working good enough to >> discuss. This patch lacks docs, but I wanted to make sure the interface >> is fine with everybody before documenting it. > > No one else had any comments, and it looks fine to me. The patch looks > OK too. It'll want a testcase, naturally. Ehm, note that the test for -data-list-register-names only works for Sparc. I must admit I don't know how to test this behaviour in a generic fashion. It might be possible to compare output of -data-list-register-names and -var-registers, but given that the latter is implemented by cloning some logic of the former, that's weak test. >> As soon as we add the code to display memory-mapped registers, there will >> be a problem that existing frontends might wish to show the memory-mapped >> registers, but not wish (at the moment) to modify the code for displaying >> regular registers. I plan to address this by either adding new >> attribute "register-kind" to the output, that can be either "core" >> or "memory-mapped", or by adding an option to -var-registers that says >> what registers to show. But that's for future. > > Or a different command to return just those? I'm not sure they should > be part of -var-registers; clients probably expect "registers" to be > "the things that should go in a registers view", which won't include > most MMIO registers. FWIW, in my case MMIO registers will go straight to registers view. I think that an interface with options to -var-registers is better that adding yet another command. - Volodya