found gdbarch solib issue

[Kris Warkentin]

So I was tracing around trying to figure out why my
sysv_fetch_link_map_offsets function was getting lost when architectures
were changing.  I noticed that <arch>_init_abi was being called which then
calls my <arch>nto_init_abi through gdbarch_init_osabi().

Problem was, at some point we're changing arches for some reason, whether
setting it from a file or whatever, and the generic init_abi is called
again.  This time, however, my handler for nto_init_abi isn't called.

The change that makes this problem go away is below but I'm not entirely
confident that it's the right thing to do.  If you look at the 'compatible'
function, ie. mips_compatible, all it's doing is comparing arches.  The
original test below is comparing pointers which I think might not be right.
Either way, if I do this change, all my worries fly away.

Any reason anyone can think of why this might be bad?

cheers,

Kris

RCS file: /cvs/src/src/gdb/osabi.c,v
retrieving revision 1.15
diff -u -5 -r1.15 osabi.c
--- osabi.c 8 Jun 2003 18:27:14 -0000 1.15
+++ osabi.c 16 Jun 2003 20:33:38 -0000
@@ -309,12 +309,11 @@

   NOTE: kettenis/20021027: There may be more than one machine
   type that is compatible with the desired machine type.  Right
   now we simply return the first match, which is fine for now.
   However, we might want to do something smarter in the future.  */
-      compatible = arch_info->compatible (arch_info, handler->arch_info);
-      if (compatible == handler->arch_info)
+      if(arch_info->compatible (arch_info, handler->arch_info))
  {
    (*handler->init_osabi) (info, gdbarch);
    return;
  }