[patch/in] Add (broken) hppa-elf target

[patch/in] Add (broken) hppa-elf target

[Andrew Cagney]

[-- Attachment #1: Type: text/plain, Size: 394 bytes --]

Hello,

This adds a config pattern to match hppa*-*-*.  It configures a very 
simple PA risc target.  The target doesn't include SOM support (ya!).

The build then barfs in hppa-tdep.c as that file is trying to suck in 
system headers (a big NO NO!).

If anyone is looking to multi-arch HPPA then, I think, getting this 
target to build will make a very good starting point.

committed,
Andrew

[-- Attachment #2: diffs --]
[-- Type: text/plain, Size: 3018 bytes --]

2002-08-18  Andrew Cagney  <ac131313@redhat.com>

	* config/pa/tm-hppa.h (hppa_store_return_value): Declare.
	(hppa_value_returned_from_stack): Declare.
	(hppa_extract_return_value): Declare.
	* config/pa/hppa.mt: New file.
	* configure.tgt: Recognize hppa*-*-*.
	* MAINTAINERS: Change HPPA target to hppa-elf.  Still broken.

Index: MAINTAINERS
===================================================================
RCS file: /cvs/src/src/gdb/MAINTAINERS,v
retrieving revision 1.195
diff -u -r1.195 MAINTAINERS
--- MAINTAINERS	18 Aug 2002 04:14:02 -0000	1.195
+++ MAINTAINERS	18 Aug 2002 16:06:49 -0000
@@ -127,7 +127,7 @@
 	ns32k		--target=ns32k-netbsd ,-Werror
 			Maintenance only
 
-	pa		(--target=hppa1.1-hp-proelf broken)
+	pa		(--target=hppa-elf broken)
 			Maintenance only
 			OBSOLETE candidate, not multi-arch
 
Index: configure.tgt
===================================================================
RCS file: /cvs/src/src/gdb/configure.tgt,v
retrieving revision 1.80
diff -u -r1.80 configure.tgt
--- configure.tgt	18 Aug 2002 04:14:02 -0000	1.80
+++ configure.tgt	18 Aug 2002 16:06:50 -0000
@@ -83,6 +83,7 @@
 hppa*-*-hpux*)		gdb_target=hppahpux ;;
 hppa*-*-hiux*)		gdb_target=hppahpux ;;
 hppa*-*-osf*)		gdb_target=hppaosf ;;
+hppa*-*-*)		gdb_target=hppa ;;
 
 i[3456]86-sequent-bsd*)	gdb_target=symmetry ;;
 i[3456]86-sequent-sysv4*) gdb_target=ptx4 ;;
Index: config/pa/hppa.mt
===================================================================
RCS file: config/pa/hppa.mt
diff -N config/pa/hppa.mt
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ config/pa/hppa.mt	18 Aug 2002 16:06:54 -0000
@@ -0,0 +1,2 @@
+TDEPFILES= hppa-tdep.o
+TM_FILE= tm-hppa.h
Index: config/pa/tm-hppa.h
===================================================================
RCS file: /cvs/src/src/gdb/config/pa/tm-hppa.h,v
retrieving revision 1.16
diff -u -r1.16 tm-hppa.h
--- config/pa/tm-hppa.h	14 Jun 2002 22:55:49 -0000	1.16
+++ config/pa/tm-hppa.h	18 Aug 2002 16:07:13 -0000
@@ -310,6 +310,7 @@
    a function return value of type TYPE, and copy that, in virtual format,
    into VALBUF.  */
 
+void hppa_extract_return_value (struct type *type, char *regbuf, char *valbuf);
 #define DEPRECATED_EXTRACT_RETURN_VALUE(TYPE,REGBUF,VALBUF) \
   hppa_extract_return_value (TYPE, REGBUF, VALBUF);
 
@@ -330,6 +331,8 @@
 /* Write into appropriate registers a function return value
    of type TYPE, given in virtual format.  */
 
+
+extern void hppa_store_return_value (struct type *type, char *valbuf);
 #define STORE_RETURN_VALUE(TYPE,VALBUF) \
   hppa_store_return_value (TYPE, VALBUF);
 
@@ -350,6 +353,8 @@
    specified in the calling convention doc. As far as I know, the only
    way to get the return value is to have the caller tell us where it
    told the callee to put it, rather than have the callee tell us.  */
+struct value *hppa_value_returned_from_stack (register struct type *valtype,
+					      CORE_ADDR addr);
 #define VALUE_RETURNED_FROM_STACK(valtype,addr) \
   hppa_value_returned_from_stack (valtype, addr)
 

Re: [patch/in] Add (broken) hppa-elf target

[Mark Kettenis]

Andrew Cagney <ac131313@ges.redhat.com> writes:

> Hello,
> 
> This adds a config pattern to match hppa*-*-*.  It configures a very 

Hi Andrew,

I just realized that there is a problem with your recente changes that
add several CPU-*-* patterns.  Inroduction of these patterns means
that we no longer detect targets as unsupported, i.e. if you add a
config pattern to match i386-*-*, this will also catch i386-ibm-aix
which I just obsoleted.

Mark

Re: [patch/in] Add (broken) hppa-elf target

[Andrew Cagney]

> Andrew Cagney <ac131313@ges.redhat.com> writes:
> 
> 
>> Hello,
>> 
>> This adds a config pattern to match hppa*-*-*.  It configures a very 
> 
> 
> Hi Andrew,
> 
> I just realized that there is a problem with your recente changes that
> add several CPU-*-* patterns.  Inroduction of these patterns means
> that we no longer detect targets as unsupported, i.e. if you add a
> config pattern to match i386-*-*, this will also catch i386-ibm-aix
> which I just obsoleted.

The above is for the cross -- default to a generic ARCH cross debugger. 
  configure.host will still detect that a native i386-ibm-aix build 
isn't supported and reject it.

Andrew

PS: To give you a headache :-)  Even though a native i386-ibm-aix won't 
build, there is a good chance that an i386-ibm-aix host will build an 
i386-ibm-aix cross debugger.  This is correct behavour because a cross 
debugger should be buildable on any host :-)

Re: [patch/in] Add (broken) hppa-elf target

[Mark Kettenis]

   Date: Sun, 18 Aug 2002 13:27:56 -0400
   From: Andrew Cagney <ac131313@ges.redhat.com>

   PS: To give you a headache :-)  Even though a native i386-ibm-aix won't 
   build, there is a good chance that an i386-ibm-aix host will build an 
   i386-ibm-aix cross debugger.  This is correct behavour because a cross 
   debugger should be buildable on any host :-)

Yup.  Except that --target=i386-ibm-aix won't give you exactly a
i386-ibm-aix cross-debuger.  It will give you the same generic i386
cross-debuger as --target=i386-elf or --target=i386-whatever-junk.
Suppose i386-ibm-aix had a rather peculiar ABI that's really
incompatible with the generic i386 ABI.  The resulting GDB would not
be very useful.  Shouldn't we somehow warn against this?

Mark

Re: [patch/in] Add (broken) hppa-elf target

[Daniel Jacobowitz]

On Sun, Aug 18, 2002 at 08:03:02PM +0200, Mark Kettenis wrote:
>    Date: Sun, 18 Aug 2002 13:27:56 -0400
>    From: Andrew Cagney <ac131313@ges.redhat.com>
> 
>    PS: To give you a headache :-)  Even though a native i386-ibm-aix won't 
>    build, there is a good chance that an i386-ibm-aix host will build an 
>    i386-ibm-aix cross debugger.  This is correct behavour because a cross 
>    debugger should be buildable on any host :-)
> 
> Yup.  Except that --target=i386-ibm-aix won't give you exactly a
> i386-ibm-aix cross-debuger.  It will give you the same generic i386
> cross-debuger as --target=i386-elf or --target=i386-whatever-junk.
> Suppose i386-ibm-aix had a rather peculiar ABI that's really
> incompatible with the generic i386 ABI.  The resulting GDB would not
> be very useful.  Shouldn't we somehow warn against this?

FWIW, GCC's configury explicitly lists and warns about obsoleted
targets.  I think this would be a good idea for GDB also.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [patch/in] Add (broken) hppa-elf target

[Andrew Cagney]

>    Date: Sun, 18 Aug 2002 13:27:56 -0400
>    From: Andrew Cagney <ac131313@ges.redhat.com>
> 
>    PS: To give you a headache :-)  Even though a native i386-ibm-aix won't 
>    build, there is a good chance that an i386-ibm-aix host will build an 
>    i386-ibm-aix cross debugger.  This is correct behavour because a cross 
>    debugger should be buildable on any host :-)
> 
> Yup.  Except that --target=i386-ibm-aix won't give you exactly a
> i386-ibm-aix cross-debuger.  It will give you the same generic i386
> cross-debuger as --target=i386-elf or --target=i386-whatever-junk.
> Suppose i386-ibm-aix had a rather peculiar ABI that's really
> incompatible with the generic i386 ABI.  The resulting GDB would not
> be very useful.  Shouldn't we somehow warn against this?

(I've ended up debugging an arm target using an x86 gdb so it is still 
useful :-)

I guess we could.  src/configure.in currently disables the ia64-elf 
target because it doesn't build.  A warning message is printed but it is 
burried in amongst all the other autoconf output.

Anyway, I think it is easier in cases such as this, to just let GDB 
built the best it can.   If a warning is really needed then perhaps have 
the OS sniffer detect and report something (Hmm, I just deleted the 
messaging indicating that the OSABI was unknown :-( ).

enjoy,
Andrew