[Patch] arch recognition fix for osabi.c

[Patch] arch recognition fix for osabi.c

[Kris Warkentin]

Here are some changes to osabi.c that allow gdb to recognize QNX binaries
properly.  The arch check change in gdbarch_init_osabi() allows the backend
abi_init handlers to run.  I believe the comment still stand - we will
probably want to do something smarter in the future.

The sniff change is only temporary.  It works reasonably well for now and
will probably stay for backwards compatability but we are also going to add
a special .note section like others OSes in the future.  Then we can check
for both.

cheers,

Kris

Changelog:
    * osabi.c (gdbarch_init_osabi): Just check arch for compatability rather
identicality.
      (generic_elf_osabi_sniff_abi_tag_sections): Add check for QNX Neutrino
binaries.


Index: osabi.c
===================================================================
RCS file: /cvs/src/src/gdb/osabi.c,v
retrieving revision 1.15
diff -u -r1.15 osabi.c
--- osabi.c 8 Jun 2003 18:27:14 -0000 1.15
+++ osabi.c 17 Jun 2003 15:32:53 -0000
@@ -311,8 +311,7 @@
   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;
@@ -430,6 +429,17 @@
       necessary yet.  */
    *os_ident_ptr = GDB_OSABI_NETBSD_ELF;
  }
+      return;
+    }
+
+  /* QNX Neutrino has ldqnx.so as its linker.  */
+  if (strcmp (name, ".interp") == 0 && sectsize > 0)
+    {
+      char *buf = alloca(sectsize);
+      bfd_get_section_contents(abfd, sect, buf, 0, sectsize);
+      buf[sectsize] = '\0'; /* Safety first boys and girls.  */
+      if(strstr(buf, "ldqnx.so"))
+        *os_ident_ptr = GDB_OSABI_QNXNTO;
       return;
     }
 }

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

[Daniel Jacobowitz]

On Tue, Jun 17, 2003 at 11:40:37AM -0400, Kris Warkentin wrote:
> Here are some changes to osabi.c that allow gdb to recognize QNX binaries
> properly.  The arch check change in gdbarch_init_osabi() allows the backend
> abi_init handlers to run.  I believe the comment still stand - we will
> probably want to do something smarter in the future.
> 
> The sniff change is only temporary.  It works reasonably well for now and
> will probably stay for backwards compatability but we are also going to add
> a special .note section like others OSes in the future.  Then we can check
> for both.
> 
> cheers,
> 
> Kris
> 
> Changelog:
>     * osabi.c (gdbarch_init_osabi): Just check arch for compatability rather
> identicality.

Your mailer is eating indentation again...

This half I'm not convinced by.  From our previous exchange I don't
think you've fully justified it.  Not approved without more discussion.

>       (generic_elf_osabi_sniff_abi_tag_sections): Add check for QNX Neutrino
> binaries.

This bit looks fine, except for two things: you've missed the coding
standards by four space characters (before left parens), and your
"safety first" check overruns the buffer (missing +1 in the alloca).

> Index: osabi.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/osabi.c,v
> retrieving revision 1.15
> diff -u -r1.15 osabi.c
> --- osabi.c 8 Jun 2003 18:27:14 -0000 1.15
> +++ osabi.c 17 Jun 2003 15:32:53 -0000
> @@ -311,8 +311,7 @@
>    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;
> @@ -430,6 +429,17 @@
>        necessary yet.  */
>     *os_ident_ptr = GDB_OSABI_NETBSD_ELF;
>   }
> +      return;
> +    }
> +
> +  /* QNX Neutrino has ldqnx.so as its linker.  */
> +  if (strcmp (name, ".interp") == 0 && sectsize > 0)
> +    {
> +      char *buf = alloca(sectsize);
> +      bfd_get_section_contents(abfd, sect, buf, 0, sectsize);
> +      buf[sectsize] = '\0'; /* Safety first boys and girls.  */
> +      if(strstr(buf, "ldqnx.so"))
> +        *os_ident_ptr = GDB_OSABI_QNXNTO;
>        return;
>      }
>  }
> 
> 
> 

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Kris Warkentin]

> > Changelog:
> >     * osabi.c (gdbarch_init_osabi): Just check arch for compatability
rather
> > identicality.
>
> Your mailer is eating indentation again...

Yeah.  It's fine in the editor - it's the cut and paste to Outlook that
buggers it.

> This half I'm not convinced by.  From our previous exchange I don't
> think you've fully justified it.  Not approved without more discussion.

Okay.  Let's use mips as an example.  The 'compatible' check returns true if
they have the same arch (ie. bfd_arch_mips).  There will be many different
values for the arch_info pointer, all with bfd_arch_mips and various other
pieces of info such as which machine type (10k, 4300, etc.) of mips it is.
The handler was registered for bfd_arch_mips with no other information.  In
the absence of the ABILITY to do anything smarter, we have to assume that if
the handler is for bfd_arch_mips, it should be run.

As it stands, if the bfd reads a file and says 'this is a tx3900' or some
such, the pointers won't be the same and my backend init_abi won't be run
even though I want it to run for all mips targets.

> >       (generic_elf_osabi_sniff_abi_tag_sections): Add check for QNX
Neutrino
> > binaries.
>
> This bit looks fine, except for two things: you've missed the coding
> standards by four space characters (before left parens), and your
> "safety first" check overruns the buffer (missing +1 in the alloca).

Doh!  Not very safe was it?  Sorry about that.  Fixed.

cheers,

Kris

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

[Kris Warkentin]

Daniel, did you have any further spare brain cycles to consider my argument?

cheers,

Kris

> > > Changelog:
> > >     * osabi.c (gdbarch_init_osabi): Just check arch for compatability
> rather
> > > identicality.
> >
> > Your mailer is eating indentation again...
>
> Yeah.  It's fine in the editor - it's the cut and paste to Outlook that
> buggers it.
>
> > This half I'm not convinced by.  From our previous exchange I don't
> > think you've fully justified it.  Not approved without more discussion.
>
> Okay.  Let's use mips as an example.  The 'compatible' check returns true
if
> they have the same arch (ie. bfd_arch_mips).  There will be many different
> values for the arch_info pointer, all with bfd_arch_mips and various other
> pieces of info such as which machine type (10k, 4300, etc.) of mips it is.
> The handler was registered for bfd_arch_mips with no other information.
In
> the absence of the ABILITY to do anything smarter, we have to assume that
if
> the handler is for bfd_arch_mips, it should be run.
>
> As it stands, if the bfd reads a file and says 'this is a tx3900' or some
> such, the pointers won't be the same and my backend init_abi won't be run
> even though I want it to run for all mips targets.
>
> > >       (generic_elf_osabi_sniff_abi_tag_sections): Add check for QNX
> Neutrino
> > > binaries.
> >
> > This bit looks fine, except for two things: you've missed the coding
> > standards by four space characters (before left parens), and your
> > "safety first" check overruns the buffer (missing +1 in the alloca).
>
> Doh!  Not very safe was it?  Sorry about that.  Fixed.
>
> cheers,
>
> Kris
>
>
>

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

[Daniel Jacobowitz]

I'm still not convinced.  I'm keeping your last message around until I
have a chance to examine what the compatible functions are really
doing.

On Thu, Jun 19, 2003 at 08:26:11AM -0400, Kris Warkentin wrote:
> Daniel, did you have any further spare brain cycles to consider my argument?
> 
> cheers,
> 
> Kris
> 
> > > > Changelog:
> > > >     * osabi.c (gdbarch_init_osabi): Just check arch for compatability
> > rather
> > > > identicality.
> > >
> > > Your mailer is eating indentation again...
> >
> > Yeah.  It's fine in the editor - it's the cut and paste to Outlook that
> > buggers it.
> >
> > > This half I'm not convinced by.  From our previous exchange I don't
> > > think you've fully justified it.  Not approved without more discussion.
> >
> > Okay.  Let's use mips as an example.  The 'compatible' check returns true
> if
> > they have the same arch (ie. bfd_arch_mips).  There will be many different
> > values for the arch_info pointer, all with bfd_arch_mips and various other
> > pieces of info such as which machine type (10k, 4300, etc.) of mips it is.
> > The handler was registered for bfd_arch_mips with no other information.
> In
> > the absence of the ABILITY to do anything smarter, we have to assume that
> if
> > the handler is for bfd_arch_mips, it should be run.
> >
> > As it stands, if the bfd reads a file and says 'this is a tx3900' or some
> > such, the pointers won't be the same and my backend init_abi won't be run
> > even though I want it to run for all mips targets.
> >
> > > >       (generic_elf_osabi_sniff_abi_tag_sections): Add check for QNX
> > Neutrino
> > > > binaries.
> > >
> > > This bit looks fine, except for two things: you've missed the coding
> > > standards by four space characters (before left parens), and your
> > > "safety first" check overruns the buffer (missing +1 in the alloca).
> >
> > Doh!  Not very safe was it?  Sorry about that.  Fixed.
> >
> > cheers,
> >
> > Kris
> >
> >
> >
> 
> 
> 

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Kris Warkentin]

I just thought of a way to rephrase the problem somewhat.

Given that I've registered an osabi handler for mips that is NOT getting run
when the arch changes to another mips machine, what method would you suggest
I use to ensure that ntomips_init_osabi() gets run?

My handler setup for mips is this:

  gdbarch_register_osabi (bfd_arch_mips, 0, GDB_OSABI_QNXNTO,
mipsnto_init_abi);

Should I perhaps be registering this for all the possible mips targets that
we want?  That is, make calls for 0, 3900, 4100, 4111, 4300, 4600, 4650,
5000, 8000, 10000?

cheers,

Kris

> I'm still not convinced.  I'm keeping your last message around until I
> have a chance to examine what the compatible functions are really
> doing.
>
> On Thu, Jun 19, 2003 at 08:26:11AM -0400, Kris Warkentin wrote:
> > Daniel, did you have any further spare brain cycles to consider my
argument?
> >
> > cheers,
> >
> > Kris
> >
> > > > > Changelog:
> > > > >     * osabi.c (gdbarch_init_osabi): Just check arch for
compatability
> > > rather
> > > > > identicality.
> > > >
> > > > Your mailer is eating indentation again...
> > >
> > > Yeah.  It's fine in the editor - it's the cut and paste to Outlook
that
> > > buggers it.
> > >
> > > > This half I'm not convinced by.  From our previous exchange I don't
> > > > think you've fully justified it.  Not approved without more
discussion.
> > >
> > > Okay.  Let's use mips as an example.  The 'compatible' check returns
true
> > if
> > > they have the same arch (ie. bfd_arch_mips).  There will be many
different
> > > values for the arch_info pointer, all with bfd_arch_mips and various
other
> > > pieces of info such as which machine type (10k, 4300, etc.) of mips it
is.
> > > The handler was registered for bfd_arch_mips with no other
information.
> > In
> > > the absence of the ABILITY to do anything smarter, we have to assume
that
> > if
> > > the handler is for bfd_arch_mips, it should be run.
> > >
> > > As it stands, if the bfd reads a file and says 'this is a tx3900' or
some
> > > such, the pointers won't be the same and my backend init_abi won't be
run
> > > even though I want it to run for all mips targets.
> > >
> > > > >       (generic_elf_osabi_sniff_abi_tag_sections): Add check for
QNX
> > > Neutrino
> > > > > binaries.
> > > >
> > > > This bit looks fine, except for two things: you've missed the coding
> > > > standards by four space characters (before left parens), and your
> > > > "safety first" check overruns the buffer (missing +1 in the alloca).
> > >
> > > Doh!  Not very safe was it?  Sorry about that.  Fixed.
> > >
> > > cheers,
> > >
> > > Kris
> > >
> > >
> > >
> >
> >
> >
>
> -- 
> Daniel Jacobowitz
> MontaVista Software                         Debian GNU/Linux Developer
>

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

[Daniel Jacobowitz]

On Tue, Jun 17, 2003 at 12:04:32PM -0400, Kris Warkentin wrote:
> > This half I'm not convinced by.  From our previous exchange I don't
> > think you've fully justified it.  Not approved without more discussion.
> 
> Okay.  Let's use mips as an example.  The 'compatible' check returns true if
> they have the same arch (ie. bfd_arch_mips).  There will be many different
> values for the arch_info pointer, all with bfd_arch_mips and various other
> pieces of info such as which machine type (10k, 4300, etc.) of mips it is.
> The handler was registered for bfd_arch_mips with no other information.  In
> the absence of the ABILITY to do anything smarter, we have to assume that if
> the handler is for bfd_arch_mips, it should be run.
> 
> As it stands, if the bfd reads a file and says 'this is a tx3900' or some
> such, the pointers won't be the same and my backend init_abi won't be run
> even though I want it to run for all mips targets.

All calls to gdbarch_register_osabi in GDB except for two use mach ==
0.  The two are mips-linux-tdep.c, which appears to be solving the same
problem - what a coincidence:
  for (arch_info = bfd_lookup_arch (bfd_arch_mips, 0);
       arch_info != NULL;
       arch_info = arch_info->next)
    {
      gdbarch_register_osabi (bfd_arch_mips, arch_info->mach, GDB_OSABI_LINUX,
                              mips_linux_init_abi);
    }
and x86-64.  For x86-64 your change is correct since BFD will catch the
different bits-per-word and return NULL.  For mips-linux-tdep it would
let you remove that loop, which I have a vague memory of being annoyed
at when it became necessary.

The check came from

2002-12-14  Mark Kettenis  <kettenis@gnu.org>

        * osabi.c: Include "gdb_assert.h" and "gdb_string.h".
        (struct gdb_osabi_handler): Remove member `arch'.  Add member
        `arch_info'.
        (gdbarch_register_osabi): Add new argument `machine'.  Use ot to
        construct a `struct bfd_arch_info' and store it in the `struct
        gdb_osabi_handler' that is created.
        (gdbarch_init_osabi): Check for compatibility based on machine
        type and architecture.
        * osabi.h (gdbarch_register_osabi): Adjust prototype and update
        comment.

So I'm not going to approve it until Mark comments.  Mark, Kris is
suggesting that the "arch_info ==" in the ->compatible check should
simply be a "NULL !=".

> > >       (generic_elf_osabi_sniff_abi_tag_sections): Add check for QNX
> Neutrino
> > > binaries.
> >
> > This bit looks fine, except for two things: you've missed the coding
> > standards by four space characters (before left parens), and your
> > "safety first" check overruns the buffer (missing +1 in the alloca).
> 
> Doh!  Not very safe was it?  Sorry about that.  Fixed.
> 
> cheers,
> 
> Kris
> 
> 
> 

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Kevin Buettner]

On Jun 19,  3:08pm, Daniel Jacobowitz wrote:

> All calls to gdbarch_register_osabi in GDB except for two use mach ==
> 0.  The two are mips-linux-tdep.c, which appears to be solving the same
> problem - what a coincidence:
>   for (arch_info = bfd_lookup_arch (bfd_arch_mips, 0);
>        arch_info != NULL;
>        arch_info = arch_info->next)
>     {
>       gdbarch_register_osabi (bfd_arch_mips, arch_info->mach, GDB_OSABI_LINUX,
>                               mips_linux_init_abi);
>     }
> and x86-64.  For x86-64 your change is correct since BFD will catch the
> different bits-per-word and return NULL.  For mips-linux-tdep it would
> let you remove that loop, which I have a vague memory of being annoyed
> at when it became necessary.

Yes, I wrote that loop, and I too was annoyed when I had to write it.

Kevin

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

[Kris Warkentin]

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

cheers,

Kris

> On Tue, Jun 17, 2003 at 12:04:32PM -0400, Kris Warkentin wrote:
> > > This half I'm not convinced by.  From our previous exchange I don't
> > > think you've fully justified it.  Not approved without more
discussion.
> >
> > Okay.  Let's use mips as an example.  The 'compatible' check returns
true if
> > they have the same arch (ie. bfd_arch_mips).  There will be many
different
> > values for the arch_info pointer, all with bfd_arch_mips and various
other
> > pieces of info such as which machine type (10k, 4300, etc.) of mips it
is.
> > The handler was registered for bfd_arch_mips with no other information.
In
> > the absence of the ABILITY to do anything smarter, we have to assume
that if
> > the handler is for bfd_arch_mips, it should be run.
> >
> > As it stands, if the bfd reads a file and says 'this is a tx3900' or
some
> > such, the pointers won't be the same and my backend init_abi won't be
run
> > even though I want it to run for all mips targets.
>
> All calls to gdbarch_register_osabi in GDB except for two use mach ==
> 0.  The two are mips-linux-tdep.c, which appears to be solving the same
> problem - what a coincidence:
>   for (arch_info = bfd_lookup_arch (bfd_arch_mips, 0);
>        arch_info != NULL;
>        arch_info = arch_info->next)
>     {
>       gdbarch_register_osabi (bfd_arch_mips, arch_info->mach,
GDB_OSABI_LINUX,
>                               mips_linux_init_abi);
>     }
> and x86-64.  For x86-64 your change is correct since BFD will catch the
> different bits-per-word and return NULL.  For mips-linux-tdep it would
> let you remove that loop, which I have a vague memory of being annoyed
> at when it became necessary.
>
> The check came from
>
> 2002-12-14  Mark Kettenis  <kettenis@gnu.org>
>
>         * osabi.c: Include "gdb_assert.h" and "gdb_string.h".
>         (struct gdb_osabi_handler): Remove member `arch'.  Add member
>         `arch_info'.
>         (gdbarch_register_osabi): Add new argument `machine'.  Use ot to
>         construct a `struct bfd_arch_info' and store it in the `struct
>         gdb_osabi_handler' that is created.
>         (gdbarch_init_osabi): Check for compatibility based on machine
>         type and architecture.
>         * osabi.h (gdbarch_register_osabi): Adjust prototype and update
>         comment.
>
> So I'm not going to approve it until Mark comments.  Mark, Kris is
> suggesting that the "arch_info ==" in the ->compatible check should
> simply be a "NULL !=".
>
> > > >       (generic_elf_osabi_sniff_abi_tag_sections): Add check for QNX
> > Neutrino
> > > > binaries.
> > >
> > > This bit looks fine, except for two things: you've missed the coding
> > > standards by four space characters (before left parens), and your
> > > "safety first" check overruns the buffer (missing +1 in the alloca).
> >
> > Doh!  Not very safe was it?  Sorry about that.  Fixed.
> >
> > cheers,
> >
> > Kris
> >
> >
> >
>
> -- 
> Daniel Jacobowitz
> MontaVista Software                         Debian GNU/Linux Developer
>

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

[Mark Kettenis]

   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

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

[Daniel Jacobowitz]

On Fri, Jul 11, 2003 at 06:26:44PM +0200, Mark Kettenis wrote:
>    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.

It doesn't declare different machines to be incompatible.  Take another
look at mips_compatible; it is actually more lenient than the default. 
But it _always_ returns a, and osabi.c expects it to return b.  I
suppose that we could change mips_compatible to return the subset type
if one has mach == 0.  But even the default doesn't do that right now.

> 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.

Which is why the word size is checked separately in
bfd_default_compatible.  mips_compatible is a whole other kettle of
worms.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Andrew Cagney]

> 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.

Can, to make life less painful, a wild card (-1 safe?) be added?

Andrew

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

[Daniel Jacobowitz]

On Fri, Jul 18, 2003 at 10:13:54AM -0400, Andrew Cagney wrote:
> >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.
> 
> Can, to make life less painful, a wild card (-1 safe?) be added?

Now that's a good idea, simple and safe.

I still believe (see my last message in this thread) that the problem
is one in osabi.c; that a return of either of its arguments from the
compatibility function should be accepted.  But if a wildcard is
preferred then that would solve the problem too, and I just want the
problem solved...

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer