Re: Available registers as a target property

[Paul Schlie <schlie@comcast.net>]

> From: Daniel Jacobowitz <drow@false.org>
> On Fri, May 06, 2005 at 08:55:59PM -0400, Paul Schlie wrote:
>> My sense is that the fundamental difference is where the information is
>> described/contained, and how the choice of which description to use is
>> conveyed to the GDB.  Although I may misunderstand, it seems more consistent
>> to enable GDB to select which of N register models to assume based upon the
>> target's identification, than requiring the target to supply a detailed
>> description of it's own register model; thereby not requiring any otherwise
>> unnecessary complexity be added to the target's GDB server implementation?
> 
> The proposal supports both.  This is the difference between
> register/feature sets and individual registers.
> 
> All hardware does not fit into nice models that GDB can know about. A
> synthesized ARM core, for instance, can have arbitrary proprietary
> coprocessors on it, designed by whoever synthesized the design.  Or
> even in ia32 land, the set of MSRs available varies wildly, and it is
> not GDB's business to track that level of details about every
> x86-compatible processor ever made.
> 
> Maintaining a central registry of all register configurations is not
> practical.

Understood, but given that these semi-customizable synthesizable processors
still need to have their configurations described to multiple tools, it
still seems that adopting a more centralized specification scheme which
enables their configuration descriptions to be more conveniently accessible
by whatever tools may choose to leverage them seems like a good thing; as
opposed to having creating discrete depositories/methods unique to each
tool.

Which is why potentially broadening the use of BFD's seemed potentially
reasonable, but do recognize it would correspondingly require broader
coordination which could complicate the effort beyond reason. So possibly
as the parameters required to sufficiently describe the logically visible
debug model of an arbitrarily configured processor subsystem becomes clear,
these same parameters could be considered to form the basis of a more
centralized target configuration description which may ultimately be
utilized by other tools.