This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: problem with fetch_link_map_offsets


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]