Re: [SH] regs command

[Pedro Alves <palves at redhat dot com>]

On 05/18/2012 01:48 PM, Joel Brobecker wrote:

>>>   /* Initialize this lazily, to avoid an initialization order
>>> > >      dependency on solib-svr4.c's _initialize routine.  */
>>> > >   if (mips_svr4_so_ops.in_dynsym_resolve_code == NULL)
>>> > >     {
>>> > >       mips_svr4_so_ops = svr4_so_ops;
>>> > >       mips_svr4_so_ops.in_dynsym_resolve_code
>>> > >         = mips_linux_in_dynsym_resolve_code;
>>> > >     }
>>> > >   set_solib_ops (gdbarch, &mips_svr4_so_ops);
>> > solib-svr4.c is as much target dependent as mips-linux-tdep.c though.
>> > The split on file name is a bit arbitrary.  It'd make a bit more sense
>> > to split around something like COMMON_OBS and TARGET_OBJS, but you'd
>> > still bump into such issues.  A "don't depend on order" rule appears
>> > simpler to understand and maintain than having to worry about
>> > hierarchies.
> And I *think* we solved that problem elsewhere, right? Basically,
> we call functions to get the ops vector. That way, no matter the
> init order, we always access initialized data... See the inf-*
> files IIRC.


Yeah, I think you're talking about inf_ptrace_target, etc.  In those
cases, the target_ops vector is heap allocated.  For statically allocated
cases, we have, e.g., ada-lang.c:

static void
initialize_ada_catchpoint_ops (void)
{
  struct breakpoint_ops *ops;

  initialize_breakpoint_ops ();
  ...

With initialize_breakpoint_ops itself bothering with init order (by
being idempotent).

Some core things that are dependent on initialization order are
handled by "initialize_foo" (no _ prefix) calls crafted in a specific
order in gdb_init.

-- 
Pedro Alves