From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kevin Buettner To: Andrew Cagney Cc: gdb-patches@sources.redhat.com, Randolph Chung Subject: Re: [hppa] Enable cross-gdb building for hppa Date: Mon, 10 May 2004 21:14:00 -0000 Message-id: <20040510141358.7dd2f21f@saguaro> References: <20040509195351.GW3965@tausq.org> <409FC122.8010009@gnu.org> X-SW-Source: 2004-05/msg00307.html On Mon, 10 May 2004 13:51:30 -0400 Andrew Cagney 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