problem with fetch_link_map_offsets

problem with fetch_link_map_offsets

[Kris Warkentin]

All of a sudden I'm getting a complaint about "No shared lib support for
this OS/ABI" from the new svr4_have_link_map_offsets function.  When I
initialize my backend tdep file, I set the fetch_link_map_offsets function.
If I break on svr4_fetch_link_map_offsets, the first couple times I see that
flmo is set to my function, then the third time it's been set back to
legacy_fetch_link_map_offsets.  I set a break on
set_solib_svr4_fetch_link_map_offsets and see it being called with my
function but it never gets called again between when I set it and when it
shows up as changed.

Can someone tell me where to set a watchpoint to catch the gdbarch data
being set?  I'm still a little shakey on how that all works.

cheers,

Kris

Re: problem with fetch_link_map_offsets

[Andrew Cagney]

> All of a sudden I'm getting a complaint about "No shared lib support for
> this OS/ABI" from the new svr4_have_link_map_offsets function.  When I
> initialize my backend tdep file, I set the fetch_link_map_offsets function.
> If I break on svr4_fetch_link_map_offsets, the first couple times I see that
> flmo is set to my function, then the third time it's been set back to
> legacy_fetch_link_map_offsets.  I set a break on
> set_solib_svr4_fetch_link_map_offsets and see it being called with my
> function but it never gets called again between when I set it and when it
> shows up as changed.
> 
> Can someone tell me where to set a watchpoint to catch the gdbarch data
> being set?  I'm still a little shakey on how that all works.

An aside, "set debug arch 1", and watch to see if any other 
architectures are being initialized or selected.

Andrew

Re: problem with fetch_link_map_offsets

[Kris Warkentin]

> > All of a sudden I'm getting a complaint about "No shared lib support for
> > this OS/ABI" from the new svr4_have_link_map_offsets function.  When I
> > initialize my backend tdep file, I set the fetch_link_map_offsets
function.
> > If I break on svr4_fetch_link_map_offsets, the first couple times I see
that
> > flmo is set to my function, then the third time it's been set back to
> > legacy_fetch_link_map_offsets.  I set a break on
> > set_solib_svr4_fetch_link_map_offsets and see it being called with my
> > function but it never gets called again between when I set it and when
it
> > shows up as changed.
> >
> > Can someone tell me where to set a watchpoint to catch the gdbarch data
> > being set?  I'm still a little shakey on how that all works.
>
> An aside, "set debug arch 1", and watch to see if any other
> architectures are being initialized or selected.

Wow...talk about verbosity.  At least now I've ruled out any other arches
being selected.  I was pretty sure that they weren't because I had set a
break on set_solib_svr4_fetch_link_map_offsets and it was only called by us.
Since that's the only interface to change the lmo function, it would seem
like it has to be happening in the solib-svr4.c file somewhere.  That's why
I was hoping to set a watchpoint.

cheers,

Kris

Re: problem with fetch_link_map_offsets

[Kevin Buettner]

On Apr 28,  4:21pm, Kris Warkentin wrote:
> All of a sudden I'm getting a complaint about "No shared lib support for
> this OS/ABI" from the new svr4_have_link_map_offsets function.  When I
> initialize my backend tdep file, I set the fetch_link_map_offsets function.

Do you mean that you're calling set_solib_svr4_fetch_link_map_offsets()
from your _initialize_XXX_tdep() function?  If so, that's not right.  It
should be done either in the ABI initialization function (e.g. see
ppc_linux_init_abi in ppc-linux-tdep.c) or in your XXX_gdbarch_init
function.

> If I break on svr4_fetch_link_map_offsets, the first couple times I see that
> flmo is set to my function, then the third time it's been set back to
> legacy_fetch_link_map_offsets.  I set a break on
> set_solib_svr4_fetch_link_map_offsets and see it being called with my
> function but it never gets called again between when I set it and when it
> shows up as changed.
> 
> Can someone tell me where to set a watchpoint to catch the gdbarch data
> being set?  I'm still a little shakey on how that all works.

Maybe...

  current_gdbarch->data[fetch_link_map_offsets_gdbarch_data->index]

?

Something like this will probably work if you suspect that it's changing
after the fact.  It probably won't work to see it initialized though.

You may also want to watch current_gdbarch to see when it changes.  I
suspect that's the problem.

Kevin

Re: problem with fetch_link_map_offsets

[Kris Warkentin]

> Do you mean that you're calling set_solib_svr4_fetch_link_map_offsets()
> from your _initialize_XXX_tdep() function?  If so, that's not right.  It
> should be done either in the ABI initialization function (e.g. see
> ppc_linux_init_abi in ppc-linux-tdep.c) or in your XXX_gdbarch_init
> function.

I'll tell you what I do and you can tell me if I'm right.  I have an
_initialize_shnto_tdep function in my sh-nto-tdep.c which calls:

gdbarch_register_osabi (bfd_arch_sh, 0, GDB_OSABI_QNXNTO, shnto_init_abi)

Within shnot_init_abi I have all my set_solib_svr4_fetch_link_map_offsets()
and other stuff.  When I watch gdb in the debugger, I see that set_svr4_flmo
is called twice, both times with my shnot_svr4_flmo function.

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.

> Maybe...
>
>   current_gdbarch->data[fetch_link_map_offsets_gdbarch_data->index]
>
> ?
>
> Something like this will probably work if you suspect that it's changing
> after the fact.  It probably won't work to see it initialized though.
>
> You may also want to watch current_gdbarch to see when it changes.  I
> suspect that's the problem.

I'll try that.  Thanks.

Kris

Re: problem with fetch_link_map_offsets

[Kevin Buettner]

On Apr 29, 11:25am, Kris Warkentin wrote:

> > Do you mean that you're calling set_solib_svr4_fetch_link_map_offsets()
> > from your _initialize_XXX_tdep() function?  If so, that's not right.  It
> > should be done either in the ABI initialization function (e.g. see
> > ppc_linux_init_abi in ppc-linux-tdep.c) or in your XXX_gdbarch_init
> > function.
> 
> I'll tell you what I do and you can tell me if I'm right.  I have an
> _initialize_shnto_tdep function in my sh-nto-tdep.c which calls:
> 
> gdbarch_register_osabi (bfd_arch_sh, 0, GDB_OSABI_QNXNTO, shnto_init_abi)
> 
> Within shnot_init_abi I have all my set_solib_svr4_fetch_link_map_offsets()
> and other stuff.  When I watch gdb in the debugger, I see that set_svr4_flmo
> is called twice, both times with my shnot_svr4_flmo function.

This sounds right.

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

Kevin

Re: problem with fetch_link_map_offsets

[Kris Warkentin]

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

Re: problem with fetch_link_map_offsets

[Kris Warkentin]

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

Re: problem with fetch_link_map_offsets

[Kevin Buettner]

On Jun 9,  5:19pm, Kris Warkentin wrote:

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

Kevin

Re: problem with fetch_link_map_offsets

[Kris Warkentin]

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

Kris

Re: problem with fetch_link_map_offsets

[Richard Earnshaw]

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

Re: problem with fetch_link_map_offsets

[Kris Warkentin]

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

Perhaps.  I'll have to talk to some of the folk here.  I think it would be
really handy to be able to recognize one of our binaries.  Thanks for the
suggestion.

cheers,

Kris

Re: problem with fetch_link_map_offsets

[Richard Earnshaw]

> > > 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.
> 
> Perhaps.  I'll have to talk to some of the folk here.  I think it would be
> really handy to be able to recognize one of our binaries.  Thanks for the
> suggestion.
> 

The note has other uses, too.  For example, it can be used to ensure that 
the kernel doesn't run applications that are intended for another 
platform, or to enable an emulation mode if running such an app, or even 
to give backwards compatibility if the kernel/user ABI changes.

R.

Re: problem with fetch_link_map_offsets

[Kris Warkentin]

> > > 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.
>
> Perhaps.  I'll have to talk to some of the folk here.  I think it would be
> really handy to be able to recognize one of our binaries.  Thanks for the
> suggestion.

Here's a fix that works right now:  If I put the code below into
generic_elf_osabi_sniff_abi_tag_sections(), the sniffer does its job.  The
problem with this is that it will only work on dynamically linked binaries.
Convenient as a stop-gap and for a certain amount of backwards
compatability.  I think the .note.qnxnto.ident section is still a good idea
though.  I tried putting one into our crtbegin.o but then programs were core
dumping so I'm doing something wrong there.  I'll have to talk to the OS
folks.

cheers,

Kris

  /* 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: problem with fetch_link_map_offsets

[Kris Warkentin]

Okay.  Looks like this fix only works for arm.  All the targets seem to call
the sniff function but at some point, the current_gdbarch is changing and
the fetch_link_map_offsets is pointing back to
legacy_fetch_link_map_offsets.

I've been stepping through all over the place and looking through the output
of set debug arch 1 and still not finding what I'm looking for.  The nearest
guess I can make is that somewhere in gdbarch_update_p, gdb is creating a
new gdbarch which is much like the one that I initialized but not quite.  I
have these nto_init_abi functions that are registered to the bfd and tied to
GDB_OSABI_QNXNTO.  Gdbarch_update_p is creating a new gdbarch, filling in
some fields, tagging it with GDB_OSABI_QNXNTO and carrying on.  Then things
fall apart because the new gdbarch has lost my fetch_link_map_offsets
pointer and current_gdbarch->data[1] is pointing back to the legacy_flmo.

Argh.

All I'm doing in my tdep init sections are things like this:

gdbarch_register_osabi (bfd_arch_sh, 0, GDB_OSABI_QNXNTO, shnto_init_abi);

Then my init_abi function sets things up with calls to
set_solib_svr4_fetch_link_map_offsets and the like.  Am I doing something
wrong?  It almost looks like things need to happen in a different order or
the init function needs to be called again or something.

Any ideas?

cheers,

Kris

> Here's a fix that works right now:  If I put the code below into
> generic_elf_osabi_sniff_abi_tag_sections(), the sniffer does its job.  The
> problem with this is that it will only work on dynamically linked
binaries.
> Convenient as a stop-gap and for a certain amount of backwards
> compatability.  I think the .note.qnxnto.ident section is still a good
idea
> though.  I tried putting one into our crtbegin.o but then programs were
core
> dumping so I'm doing something wrong there.  I'll have to talk to the OS
> folks.
>
> cheers,
>
> Kris
>
>   /* 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;
>     }
>
>
>