Re: RFC: Available registers as a target property

[Paul Schlie <schlie at comcast dot net>]

> Daniel Jacobowitz <drow at false dot org> 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?