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

["Kris Warkentin" <kewarken@qnx.com>]

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
>