Re: [SH] regs command

["Maciej W. Rozycki" <macro@codesourcery.com>]

On Thu, 17 May 2012, Joel Brobecker wrote:

> > I tend to agree with Mark that changing the init order in response to
> > this problem is perhaps not wise.
> 
> OK, I think that settles it.

 While I agree that this command deprecation case may not be important 
enough to make a decision on an internal API change weeks before a 
release, that does not mean the problem is not there.

 For example as recently as yesterday I came across this piece (in 
mips-linux-tdep.c):

static struct target_so_ops mips_svr4_so_ops;
[...]

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

that I find all but clean -- I can't even tell straight away, without 
studying all the code involved and perhaps experimenting, if this indeed 
is going to work correctly regardless of whether this is run before or 
after the other piece referred.

 And of course, this being an internal API that we can change arbitrarily 
at any time, including to reverse an earlier decision that turned out not 
to work as well as expected, I am not thoroughly convinced this moment is 
any worse than any other.

  Maciej