Re: problem with fetch_link_map_offsets

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

Okay, I think I've found the problem but I'm not sure what to do about it.

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.

Is there any way to make my osabi "stick"?

cheers,

Kris

> > > I also observe that svr4_have_link_map_offsets is called three times
in
> the
> > > process of attaching to the remote proces.  The first two are fine -
> flmo is
> > > still pointing to the qnx version.  The third time it's pointing to
the
> > > legacy_flmo though.  I can't figure out why.
> >
> > When you figure it out, let me know why too...
>
> Interesting.  I've been doing a refactor of our gdb port and, for no
> particular reason, I started with sh4.  Just for chuckles, I finished our
> i386 port and I'm not getting the same "No shared library support" error.
I
> wonder if there's something specific in the sh4 version that's overriding
my
> settings.  I was watching current_gdbarch and it did seem to be changing
> quite a bit.  Perhaps you're right and the problem lies in there.
>
> cheers,
>
> Kris
>
>