From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrew Cagney <ac131313@cygnus.com>
To: Kevin Buettner <kevinb@cygnus.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [PATCH] solib-svr4.c: Fix set_solib_svr4_fetch_link_map_offsets
Date: Fri, 21 Sep 2001 19:32:00 -0000
Message-id: <3BABF816.9040308@cygnus.com>
References: <1010920205607.ZM17368@ocotillo.lan>
X-SW-Source: 2001-09/msg00296.html

> 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