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

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

[Randolph Chung]

In reference to a message from Randolph Chung, dated May 09:
> This patch enables cross-gdb building for hppa using the same kludge as
> other archs. What's a more proper way to fix this?

i got some private feedback that it should be more like this. ok to
apply?

randolph

2004-05-10  Randolph Chung  <tausq@debian.org>

	* config/pa/linux.mt (TM_FILE): Use new tm-linux.h for hppa-linux
	target.
	* config/pa/tm-linux.h: New file.

Index: gdb/config/pa/linux.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/pa/linux.mt,v
retrieving revision 1.1
diff -u -p -r1.1 linux.mt
--- gdb/config/pa/linux.mt	29 Apr 2004 03:36:50 -0000	1.1
+++ gdb/config/pa/linux.mt	10 May 2004 14:15:04 -0000
@@ -1,3 +1,3 @@
 # Target: HP PA-RISC running Linux
 TDEPFILES= hppa-tdep.o hppa-linux-tdep.o glibc-tdep.o solib.o solib-svr4.o
-TM_FILE=tm-hppa.h
+TM_FILE=tm-linux.h
--- /dev/null	2004-05-03 08:05:05.000000000 -0400
+++ gdb/config/pa/tm-linux.h	2004-05-09 17:13:07.000000000 -0400
@@ -0,0 +1,27 @@
+/* Definitions to target GDB to GNU/Linux on hppa-linux.
+   Copyright 1992, 1993, 2000 Free Software Foundation, Inc.
+
+   This file is part of GDB.
+
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 2 of the License, or
+   (at your option) any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program; if not, write to the Free Software
+   Foundation, Inc., 59 Temple Place - Suite 330,
+   Boston, MA 02111-1307, USA.  */
+
+#ifndef TM_LINUX_H
+#define TM_LINUX_H
+
+#include "pa/tm-hppa.h"
+#include "config/tm-linux.h"
+
+#endif /* #ifndef TM_LINUX_H */

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

[Daniel Jacobowitz]

On Mon, May 10, 2004 at 08:09:47AM -0700, Randolph Chung wrote:
> In reference to a message from Randolph Chung, dated May 09:
> > This patch enables cross-gdb building for hppa using the same kludge as
> > other archs. What's a more proper way to fix this?
> 
> i got some private feedback that it should be more like this. ok to
> apply?
> 
> randolph
> 
> 2004-05-10  Randolph Chung  <tausq@debian.org>
> 
> 	* config/pa/linux.mt (TM_FILE): Use new tm-linux.h for hppa-linux
> 	target.
> 	* config/pa/tm-linux.h: New file.

By analogy with the other Linux targets, yes, OK.

> +   Copyright 1992, 1993, 2000 Free Software Foundation, Inc.

Fix that though.

-- 
Daniel Jacobowitz

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

[Andrew Cagney]

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?

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

[Kevin Buettner]

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