sol-thread.c core_ops oddity

[dje@google.com (Doug Evans)]

The code says it doesn't care which of _initialize_sol_thread
or _initialize_corelow is run first (and clearly one would rather
not care).

corelow.c:
/* non-zero if we should not do the add_target call in
   _initialize_corelow; not initialized (i.e., bss) so that
   the target can initialize it (i.e., data) if appropriate.
   This needs to be set at compile time because we don't know
   for sure whether the target's initialize routine is called
   before us or after us. */
int coreops_suppress_target;

and sol-thread.c has:
/* We suppress the call to add_target of core_ops in corelow because
   if there are two targets in the stratum core_stratum,
   find_core_target won't know which one to return.  See corelow.c for
   an additonal comment on coreops_suppress_target.  */
int coreops_suppress_target = 1;

Ok, so far so good.

However, if _initialize_sol_thread is run first then the order is:

sol-thread.c:
  init_sol_core_ops ();
  [...]
  memcpy (&orig_core_ops, &core_ops, sizeof (struct target_ops));
  memcpy (&core_ops, &sol_core_ops, sizeof (struct target_ops));
  add_target (&core_ops);

then corelow.c:
  init_core_ops ();

and afterwards orig_core_ops is still full of zeroes (bad for
later calls to orig_core_ops.mumble), and the
core_ops target is filled with the values from corelow.c
(undoing the work of init_col_core_ops).

Obviously I'm missing something.
I don't have a solaris system to see what really happens,
can someone fill in the missing piece that makes the above work?