Re: [ping] Re: [Patch] arch recognition fix for osabi.c

[Mark Kettenis <kettenis at chello dot nl>]

   From: "Kris Warkentin" <kewarken@qnx.com>
   Date: Fri, 11 Jul 2003 11:04:29 -0400

   Mark, Daniel had suggested that you were the end of the line as far as
   approving this change.

   Thread starts here:
   http://sources.redhat.com/ml/gdb-patches/2003-06/msg00562.html

Hmm, I folloed that thread, and I have some things to say about it.  I
just never did :-(.

The code is deliberately written the way it is.  The idea is that for
each CPU architecture we have a number of processors.  Some of these
are compatible with each other.  Others aren't.  The trick is to find
the ISA that is most compatible.  Most processor families out there
are backwards compatible, which basically means that a new processor
is based on ISA of its predecessor and adds some functionality to
that.  For processor families that work like that,
bfd_default_compatible does the right thing, and the code in
gdbarch_init_osabi selects an OSABI/ISA that's a subset of the desired
ISA.

Apparently this doesn't work for MIPS, since BFD declares different
processors (which it calls "machines") to be incompatible.  I'm not
quite familiar with MIPS, but I suppose this is not quite true, but
that the various MIPS processors cannot be mapped on a one-dimensional
quantity that expresses the features of the various CPU's.  That could
be a valid reason why the MIPS "compatibility function" is written the
way it is.  Perhaps it can be improved?  If so, I think that's the way
to go.  Otherwise, I think you should register for all CPU types that
you support.

One could argue that if one registers a handler for the "default
machine" that this should apply for all machines within an
architecture, but that breaks down for architectures that support both
32-bit and 64-bit machines.

Mark