This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [PATCH] solib-svr4.c: Fix set_solib_svr4_fetch_link_map_offsets
- To: Kevin Buettner <kevinb at cygnus dot com>
- Subject: Re: [PATCH] solib-svr4.c: Fix set_solib_svr4_fetch_link_map_offsets
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Fri, 21 Sep 2001 22:31:50 -0400
- Cc: gdb-patches at sources dot redhat dot com
- References: <1010920205607.ZM17368@ocotillo.lan>
> I recently attempted to use set_solib_svr4_fetch_link_map_offsets() to
> establish a Linux/PPC specific link map fetcher, but discovered a
> number of problems. One of them is as follows... I attempted to call
> set_solib_svr4_fetch_link_map_offsets() from rs6000_gdbarch_init().
> The <arch>_gdbarch_init() functions (as they are commonly named) are
> used to allocate and initialize a gdbarch struct which is then installed
> to define a new "architecture" after this function returns.
First an fyi. Elena found a cute bug in gdbarch's init sequence - it
leaves the old architecture installed while it is creating the new
architecture vis:
- create new architecture
- swap out old architecture
- install new architecture
- initialize remainder of new architecture
This leads to all sorts of confusion such as what you encountered here.
I'm working on a patch that will change the initialization behavour so
that it:
- swaps out the old architecture
- creates the new architecture
- installs new architecture
- initializes remainder of new architecture
I recall NickD encountering a similar situation to yours. The
gdbarch_data object's behavour was changed to better handle this situtation.
Instead of having a global variable, have you looked at registering a
data pointer and then calling set_gdbarch_data(), from
set_solib_svr4_fetch_link_map_offsets(), to set it?
The only potential problem I can see with this is with non- multi-arch
but there, looking at the code I think it is already handled.
Andrew