Re: Available registers as a target property

[Paul Schlie <schlie at comcast dot net>]

> From: Daniel Jacobowitz <drow@false.org>
>> On Fri, May 06, 2005 at 06:46:38PM -0400, Paul Schlie wrote:
>>> Daniel Jacobowitz wrote:
>>> ...
>>> Today, the contents of the register cache and the layout of GDB's regnum
>>> space are determined by the gdbarch.  There are several hooks for this,
>>> primarily these three:
>>> 
>>>        num_regs
>>>        register_name
>>>        register_type
>>> 
>>> The gdbarch determines what raw registers are available.  But this isn't a
>>> perfect match with what raw registers are _really_ available, because the
>>> gdbarch only has the clues we use to select a gdbarch available: things like
>>> byte order and BFD machine number.  At best, those tell us what registers
>>> the binary we're debugging requires.  The runtime set of registers we can
>>> see are a property of the target, not of the gdbarch.
>>> ...
>> 
>> Might it be more appropriate to enable gdbarch to be extended to enable the
>> more specific description of a particular target component and mode; as
>> opposed to pushing the requirement of a target to provide detailed register
>> etc. information about itself when all that should be necessary should be
>> for it to more specifically identify itself and present mode if any, thereby
>> enabling a correspondingly more precise gdbarch description to be selected
>> as the basis of it's logically visible model?
> 
> Do you have a concrete suggestion?  This sounds not fundamentally
> different from what I am doing.

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?

Where if a logical register/memory model description were formalized more
centrally, (possibly within a more detailed BFD for the target architecture)
then it may be more broadly leveraged my multiple tools, i.e. compiler,
simulator, etc. in time, as opposed to being encapsulated in a GDB specific
target implementation).

Have I misunderstood your proposed approach?