Re: problem with fetch_link_map_offsets

[Richard Earnshaw <rearnsha@arm.com>]

> > > Say, for example, I go into arm-tdep.c and comment out the section that
> > > registers a gdbarch osabi sniffer.  Now my arm port works fine: it uses
> > > GDB_OSABI_QNXNTO and everything is hunky-dory.  So the problem is that
> the
> > > sniffer says, "Oh, it's GDB_OSABI_ARM_APCS, let's set that up." and then
> all
> > > of my init stuff is out the door.
> > >
> > > The question is, how do I deal with this?  There is nothing to
> distinguish a
> > > Neutrino binary from any other elf file.  I tried registering another
> > > sniffer that just returned GDB_OSABI_QNXNTO but then it squawked that it
> got
> > > two osabi results.  I'm assuming that this is probably what I'm running
> into
> > > on all my targets.
> >
> > It sounds to me like the problem is with the sniffer(s).  If the sniffer
> > is determining GDB_OSABI_ARM_APCS for a QNX binary, that's bad and the
> > sniffer ought to be fixed.
> 
> Yeah but....a QNX binary is just an ordinary elf binary.  There are no
> special sections or magic in there for the sniffer to catch.  Hence my
> problem.  Perhaps it should be returning unknown so that another sniffer
> (like my one liner) could get it?
> 

NetBSD binaries look like ordinary ELF too, as do Linux.  The only way to 
resolve this is to arange for the crt0.o file to contain some magic that 
GDB can find.  Normally this is a special .note section.

Can you not arrange for QNX binaries to have such a note and then add that.

R.