[RFA] New register definition interface

[Andrew Cagney]

Nick Duffek wrote:

> The same issue applies to cli-regs.c: cliregs_init() attaches memory to
> each architecture even if the architecture hasn't set cliregs_info() as
> its do_registers_info callback.
> 
> Some possible solutions:
> 
>   1. Each competing module implementation introduces a gdbarch variable
>      USE_<module-implementation> that architectures must set to 1 if
>      they're using that implementation.  For example:

I don't think it will scale.  It is a bit like those
GDB_ARCHITECTURE_IS_D10V et.al. we'd all like to get rid of.  The tests
should be for functionality not implementation.

However, a hack of yes/no ``register_module_installed_p'' flag might be
useful so that the default case (regcache) knows to not install its
self.

>   2. Each module introduces a gdbarch variable MODULE_<module-name> that
>      architectures must set to an implementation-unique value.

Definitly not this one.  Look at the spaghetti found in sim/common (yes
I'm in part to blame for that one :-)

>   3. Introduce a gdbarch interface to query function pointers.  Competing
>      module implementations can use these to check whether they're being
>      used by the current architecture.  For example:
> 
>        if (GET_DO_REGISTERS_INFO () != cliregs_info)
>          return;

I don't think it should be necessary.  Module implementations shouldn't
be competing - once a module, for a given architecture, is selected the
competing modules should never be seen again.  Did I mention sim/common
:-)

The only exception would be where gdbarch asks the question ``has any
module been installed?''  If no - install the default.

>        /* allocate memory */
> 
>      To avoid the footprint of a GET_*() function for every gdbarch.sh
>      entry, a per-entry flag could be added that controls whether that
>      function is needed.

4.	Add a function like:

		set_gdbarch_data (struct gdbarch *gdbarch,
			struct gdbarch_data *handle,
			void *value);

	so that instead of waiting for gdbarch to call your
	module, your module, as part of its set-up, calls
	gdbarch vis:

	gdbarch calls ..._gdbarch_init()
	-> calls your_module's_init_or_setup_or_something()
	-> calls set_gdbarch_data (gdbarch, your_modules_handle,
your_modules_data);
	-> calls set_various_other_methods (...);

	(mumble something about fine print, memory leaks and deleting
architectures :-)

	I wouldn't be too worried if it for the short term (for GDB that is
	about a year :-) build_regcache() still allocated a buffer - that is an
	implementation issue (like using bubble sort :-).  I'm worried about
	interfaces not implementations :-).  Just document the problem in the
	code and TODO files.

	Alternativly, like you were outlining, some sort of check to see if
	a competing module hasn't already been installed.

Long long term, the register stuff could be combined into a group so
that it are installed as a block - instead of the N separate register
methods.  Again, that is a separate problem.

	Andrew