found gdbarch solib issue

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;
  }

Re: found gdbarch solib issue

[Daniel Jacobowitz]

On Mon, Jun 16, 2003 at 04:42:39PM -0400, Kris Warkentin wrote:
> 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?

Shouldn't it be returning arch_info anyway?  Why isn't it?  Is it
returning handler->arch_info?

> -      compatible = arch_info->compatible (arch_info, handler->arch_info);
> -      if (compatible == handler->arch_info)
> +      if(arch_info->compatible (arch_info, handler->arch_info))

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: found gdbarch solib issue

[Kris Warkentin]

> Shouldn't it be returning arch_info anyway?  Why isn't it?  Is it
> returning handler->arch_info?

That's what was puzzling me.  I was looking through the linked list of 10
million mips arches and thinking what the odds were of compatible ever
equalling the handler arch_info.  Seems to me that the return value might be
useful in some circumstances but in this case it should be a boolean, "am I
compatible or not?"

> > -      compatible = arch_info->compatible (arch_info,
handler->arch_info);
> > -      if (compatible == handler->arch_info)
> > +      if(arch_info->compatible (arch_info, handler->arch_info))

cheers,

Kris