Re: RFC: Available registers as a target property

Paul Schlie
2005-05-17T23:08:43Z

> 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?