Re: [RFA] New register definition interface

[Nick Duffek <nsd at redhat dot com>]

On 15-Jan-2001, Andrew Cagney wrote:

>It is much easier to justify the acceptance of your changes if there is
>a real live working example.  Especially one that demonstrates how easy
>(?) it is to update an existing target.

I agree, but it's not something I'll be able to do immediately.

>	o	sort out the cli/cli* stuff so that
>		it is independant of regs.c

You've convinced me.  I've done most of that work, but due to constraints
in my schedule at the moment, it might be a few weeks before I can post
the tested patch.

There's one technical problem: when an architecture selects one of several
competing module implementations, the other implementations shouldn't
initialize themselves for that architecture.

For example, regcache.c does this in _initialize_regcache():

   register_gdbarch_swap (NULL, 0, build_regcache);

build_regcache() attaches a chunk of malloc()ed memory to each
architecture.  That memory is wasted in architectures that use regs.c
instead of regcache.c.

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:

        set_gdbarch_do_registers_info (gdbarch, cliregs_info);
        set_gdbarch_use_cliregs (gdbarch, 1);

     cliregs_init() would check USE_CLIREGS before allocating memory.

     This doesn't work well for regcache.c: each existing architecture
     would need to add "set_gdbarch_use_regcache (gdbarch, 1)" to its
     initialization routine, or else each future architecture using regs.c
     would need to call "set_gdbarch_use_regcache (gdbarch, 0)".

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

        set_gdbarch_do_registers_info (gdbarch, cliregs_info);
        set_gdbarch_module_registers_info (gdbarch, MODULE_CLIREGS);

     This requires a new header file containing all the MODULE_*
     definitions.

  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;
       /* 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.

I'm partial to option 3, and I volunteer to implement it if you give
pre-approval to the approach.

Speaking of gdbarch.sh changes, what do you think about the idea of
translating gdbarch.sh into C and automatically generating gdbarch.[ch] as
transient compile-time entities?  Running gdbarch.sh takes about 25
seconds on my 650MHz Pentium, and I often forget to run it after applying
or reverting patches that change it.

Nick