Re: RFC: Available registers as a target property

[Paul Schlie <schlie at comcast dot net>]

> I was thinking about an architecture with multiple configurations (registers),
> such as Arc, Tensilica, ARM coprocessors (?), etc.

> Having a single daemon supporting these multiple (arbitrary) configurations
> would probably be easier for JTAG probe vendors. Since GDB certainly needs to
> know about the particular configuration, the daemon wouldn't need to be
> modified for each configuration.
>
>> I don't want to support both directions just for kicks, but there may
>> be value here that I haven't thought of yet.  That's why I asked
>> Tensilica for feedback.
>
> I understand. I was just wondering if this would be useful and actully agree
> that your proposal makes much more sense and that the target should know about
> the configuration.
>
> In our case, the daemon currently doesn't know about a particular
> configuration, and GDB only queries for registers the processor (better) has.
> For example, to read 'special register' <SR>, OCD simply issues a rsr a2,<SR>
> and doesn't know if this <SR> really exists.

It seems that there are two fundamental models which may be adopted:

- refine GDB to be fully architecturally neutral, whereby all target
  specific architectural details are provided by the target; including
  but not limited to binary code encoding format, disassembly definitions,
  type encoding definitions, symbolic and semantic register definition,
  specification logical register names, types, purpose {GP pointer/data,
  SP, FP, PC, SR, etc. including their encoding {endian, signess, fixed/
  floating point encoding}}, logical/physical memory space definition
  address range, address resolution, segmentation, etc.}, not to mention
  potentially countless control registers which may be present to control
  the cache, MMU, FPU, etc. configurations, and/or operating modes; and
  possibly even the target interface protocol specification.

- refine GDB to enable these various potential target specific details to
  be extracted from a target definition/configuration binary specification
  directly, likely as directed by the user and possibly further refined
  after subsequently querying the target. Essentially leaving the target
  interface to be primarily responsible for GDB <=> target protocol
  translation, being essentially analogous to the driver for an I/O device)

 (Although not vastly dissimilar, it likely boils down to where one wants to
 draw the line between the division of responsibility between the debugger
 and the target interface processes; where personally regardless of where,
 I simply believe all target architectural specification information should
 be consolidated for the benefit of other tools, rather than being scattered
 all over the place, or rely on proprietary sources of this information,
 being "hidden" in a "propriety target interface".)