From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11068 invoked by alias); 17 May 2005 23:08:43 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 10288 invoked from network); 17 May 2005 23:08:34 -0000 Received: from unknown (HELO sccrmhc13.comcast.net) (204.127.202.64) by sourceware.org with SMTP; 17 May 2005 23:08:34 -0000 Received: from [10.0.1.2] (c-24-61-199-96.hsd1.nh.comcast.net[24.61.199.96]) by comcast.net (sccrmhc13) with SMTP id <2005051723083301600do9cve>; Tue, 17 May 2005 23:08:33 +0000 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Tue, 17 May 2005 23:08:00 -0000 Subject: Re: RFC: Available registers as a target property From: Paul Schlie To: Daniel Jacobowitz , Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-SW-Source: 2005-05/txt/msg00175.txt.bz2 > Daniel Jacobowitz writes: > This is a much-revised version of the original proposal, based on all > the feedback I've gotten and an additional week thinking about the > problem. As before, I would appreciate feedback. Otherwise, I think > this is just about sufficiently baked to implement. > ... Upon also having the opportunity to thing further about this, I agree that there's value in being able to define logical registers which may be more target specific than traditionally defined/visible within the architectural description files; and possibly even more generalized? - more specifically, although I still believe that any register descriptions which are logically part of the machine's core ISA belong with and should correspond to that target's architectural definitions as would be seemingly necessary to correspond to it's disassembler register definitions and presumptions (as any alterative doesn't seem to minimally confusing, unless I misunderstand?) - however as there are often logical registers which are considered supplementary to even non-configurable architectures, often representing control registers associated with MMU, Cache, or other closely coupled CPU subsystems which would be nice to define a "view of" more generally (including but not limited to memory mapped I/O registers, etc.). So wonder if some hybrid mechanism, similar to that which you describe may be most ideally flexible, and sufficient to meet your goals: - presume that (by practical necessity) all logical registers which are part of a target's core architectural programming model which by definition should directly correspond to those definitions presumed by it's disassembler are sourced though gdbarch definitions, as seemingly required if they are to correspond? - enable extended logical register views to be defined either by extended definitions via gdgarch, or the target (as you've both specified), and alternatively simply a configuration file (which may potentially scripted to load via an init file script to specify extended register views for those which may be memory or I/O space mapped.) - where these extended architectural register definitions merely provide a convenient view of the logical state of the machine, which may be mapped either to specific registers which the target stub may need to be specifically aware of how to access through target specific jtag specified scan locations etc. or may simply be memory or I/O space mapped, as is often the case for extended control registers, in which case only the corresponding address and precision, would seem to need to be specified to enable GDB to request updates from the target, which would likely be useful for many existing target stubs for example? (where targets which must access extended registers through non-generalized means may publish there existence directly through their target interface stub). So in rough summary: - presume core architectural and disasssembly machine descriptions are sourced in some correlated manor (so they hopefully agree) - non-core hard-registers which need direct specialized access may be described through gdbarch, or published via the target stub. - non-core generalized memory/i-o space mapped logical register descriptions may be sourced either through gdbarch, the target, or an init file. Just as a thought, and hope that this slight generalization of your proposal might be found potentially helpful?