Re: [hppa] Enable cross-gdb building for hppa

[Kevin Buettner <kevinb at redhat dot com>]

On Mon, 10 May 2004 13:51:30 -0400
Andrew Cagney <cagney@gnu.org> wrote:

> > This patch enables cross-gdb building for hppa using the same kludge as
> > other archs. What's a more proper way to fix this?
> 
> Good question.  The gdbarch_data mechanism appears to have been ironed 
> out.  I guess having the shlib code maintain its own per osabi info.
> 
> Kevin?

IIRC, the problem is that SOLIB_ADD (and related macros) are defined
in multiple locations.  The definition in solib.h is the preferred
definition, but the other definitions are still needed for shared
library support on other platforms.  To make things more complicated,
not all builds of GDB require shib machinery, so there are some ifdefs
which disable chunks of code when SOLIB_ADD is not defined.

Long term, we want to get rid of these other definitions (as well as
the SOLIB_ADD ifdefs) and have all calls to the shlib machinery go
through solib.c.  In order to manage the problem of competing
SOLIB_ADD (and company) macros, we can either multiarch these or allow
solib.c (or some adjunct) to privately multiarch them.  I'm guessing
that the latter is what Andrew is referring to above.

Within the solib.c regime (which is where we want all of the other
solib implementations to eventually migrate), switching between
different solib backends is currently accomplished by changing the
value of the global variable current_target_so_ops.  This global could
be eliminated in favor of the gdbarch_data mechanism too.  In either
case, we'll need to introduce an interface which allows for switching
from one solib backend to another.

It would be nice to be able to accomodate several solib mechanisms
concurrently, e.g. solib-svr4 and an XFree86 module loader.  This
implies that the upper level solib code needs to be aware of some
relevant set of backends.  Sniffing code would be used to determine
whether a particular backend should be activated or not.

Kevin