Re: [RFA] New register definition interface

[Nick Duffek <nsd at redhat dot com>]

On 16-Jan-2001, Andrew Cagney wrote:

>4.	Add a function like:
>
>		set_gdbarch_data (struct gdbarch *gdbarch,
>			struct gdbarch_data *handle,
>			void *value);
[...]
>	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 (...);

That looks good to me.  It's very similar to what regs.c does, except that
it calls set_gdbarch_register_list() instead of set_gdbarch_data().
Specifically:

  1. <arch>_gdbarch_init() in <arch>-tdep.c calls regs_init_finish().
  2. regs_init_finish() calls set_gdbarch_register_list().
  3. regs_init_finish() also calls set_gdbarch_num_regs() and various
     other set_gdbarch_*() functions.

For regs.c, I really need to do the above or something similar, because
the information collected between regs_init_start(<gdbarch>) and
regs_init_finish() must be attached to <gdbarch>.

For cli-regs.c, I can use register_gdbarch_data() if I'm willing to waste
memory.  I can deal with the memory waste by:

  1. ignoring it;
  2. using regs.c's approach with e.g. CLIREGS_INTERNAL instead of
     REGISTER_LIST;
  3. implementing set_gdbarch_data().

I'd prefer 2 or 3.  Do you have a preference?

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

Since we're talking hacks, I think I might as well use REGISTER_LIST
rather than adding a new REGISTER_MODULE_INSTALLED_P method.

Nick