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


> 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


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