function parameters regression

function parameters regression

[Philippe De Muyter]

On m68k-motorola-sysv (COFF), the following tests fail, because of
a hp-specific new code in valops.c.
Can someone fix that ?  For me, testing only `using_gcc' seems too wide.

p t_func_values(add,func_val2)
You cannot use function <add> as argument.
You must use a pointer to function type variable. Command ignored.
(gdb) FAIL: gdb.base/callfuncs2.exp: p t_func_values(add,func_val2)
p t_func_values(func_val1,doubleit)
You cannot use function <doubleit> as argument.
You must use a pointer to function type variable. Command ignored.
(gdb) FAIL: gdb.base/callfuncs2.exp: p t_func_values(func_val1,doubleit)
p t_call_add(func_val1,3,4)
$48 = 7
(gdb) PASS: gdb.base/callfuncs2.exp: p t_call_add(func_val1,3,4)
p t_call_add(add,3,4)
You cannot use function <add> as argument.
You must use a pointer to function type variable. Command ignored.
(gdb) FAIL: gdb.base/callfuncs2.exp: p t_call_add(add,3,4)

Culprit code :
      /*elz: this code is to handle the case in which the function to be called
        has a pointer to function as parameter and the corresponding actual argu
ment
        is the address of a function and not a pointer to function variable.
        In aCC compiled code, the calls through pointers to functions (in the bo
dy
        of the function called by hand) are made via $$dyncall_external which
        requires some registers setting, this is taken care of if we call
        via a function pointer variable, but not via a function address.
        In cc this is not a problem. */

      if (using_gcc == 0)
        if (param_type)
          /* if this parameter is a pointer to function*/
          if (TYPE_CODE (param_type) == TYPE_CODE_PTR)
            if (TYPE_CODE (param_type->target_type) == TYPE_CODE_FUNC)
              /* elz: FIXME here should go the test about the compiler used
                    to compile the target. We want to issue the error
                    message only if the compiler used was HP's aCC.
                    If we used HP's cc, then there is no problem and no need
                    to return at this point */
              if (using_gcc == 0) /* && compiler == aCC*/
                /* go see if the actual parameter is a variable of type
                pointer to function or just a function */
                if (args[i]->lval == not_lval)
                  {
                    char *arg_name;
                    if (find_pc_partial_function((CORE_ADDR)args[i]->aligner.con
tents[0], &arg_name, NULL, NULL))
                      error("\
You cannot use function <%s> as argument. \n\
You must use a pointer to function type variable. Command ignored.", arg_name);
                  }

function parameters regression

[Philippe De Muyter]

On m68k-motorola-sysv (COFF), the following tests fail, because of
a hp-specific new code in valops.c.
Can someone fix that ?  For me, testing only `using_gcc' seems too wide.

p t_func_values(add,func_val2)
You cannot use function <add> as argument.
You must use a pointer to function type variable. Command ignored.
(gdb) FAIL: gdb.base/callfuncs2.exp: p t_func_values(add,func_val2)
p t_func_values(func_val1,doubleit)
You cannot use function <doubleit> as argument.
You must use a pointer to function type variable. Command ignored.
(gdb) FAIL: gdb.base/callfuncs2.exp: p t_func_values(func_val1,doubleit)
p t_call_add(func_val1,3,4)
$48 = 7
(gdb) PASS: gdb.base/callfuncs2.exp: p t_call_add(func_val1,3,4)
p t_call_add(add,3,4)
You cannot use function <add> as argument.
You must use a pointer to function type variable. Command ignored.
(gdb) FAIL: gdb.base/callfuncs2.exp: p t_call_add(add,3,4)

Culprit code :
      /*elz: this code is to handle the case in which the function to be called
        has a pointer to function as parameter and the corresponding actual argu
ment
        is the address of a function and not a pointer to function variable.
        In aCC compiled code, the calls through pointers to functions (in the bo
dy
        of the function called by hand) are made via $$dyncall_external which
        requires some registers setting, this is taken care of if we call
        via a function pointer variable, but not via a function address.
        In cc this is not a problem. */

      if (using_gcc == 0)
        if (param_type)
          /* if this parameter is a pointer to function*/
          if (TYPE_CODE (param_type) == TYPE_CODE_PTR)
            if (TYPE_CODE (param_type->target_type) == TYPE_CODE_FUNC)
              /* elz: FIXME here should go the test about the compiler used
                    to compile the target. We want to issue the error
                    message only if the compiler used was HP's aCC.
                    If we used HP's cc, then there is no problem and no need
                    to return at this point */
              if (using_gcc == 0) /* && compiler == aCC*/
                /* go see if the actual parameter is a variable of type
                pointer to function or just a function */
                if (args[i]->lval == not_lval)
                  {
                    char *arg_name;
                    if (find_pc_partial_function((CORE_ADDR)args[i]->aligner.con
tents[0], &arg_name, NULL, NULL))
                      error("\
You cannot use function <%s> as argument. \n\
You must use a pointer to function type variable. Command ignored.", arg_name);
                  }
From pb@nexus.co.uk Mon Apr 12 04:35:00 1999
From: Philip Blundell <pb@nexus.co.uk>
To: gdb-patches@cygnus.com
Subject: patch to use strerror in gdbserver
Date: Mon, 12 Apr 1999 04:35:00 -0000
Message-id: <E10Wdq9-0002bJ-00@fountain.nexus.co.uk>
X-SW-Source: 1999-04/msg00008.html
Content-length: 2262

Some of the gdbserver code has trouble on Linux with GNU libc 2.1 because it 
redeclares sys_errlist in a way that conflicts with the library headers.  
Since libiberty provides strerror on platforms that don't have it, we might as 
well make use of it.

1999-04-11  Philip Blundell  <philb@gnu.org>

	* gdbserver/utils.c (perror_with_name): Use strerror rather than
	sys_errlist.  Include <errno.h>, don't declare errno directly.
	* gdbserver/gdbreplay.c (perror_with_name): Likewise.
	
diff -u --recursive --new-file /home/phil/gdb/clean/gdb-4.17/gdb/gdbserver/gdbreplay.c gdb/gdbserver/gdbreplay.c
--- /home/phil/gdb/clean/gdb-4.17/gdb/gdbserver/gdbreplay.c	Sun Apr 11 21:57:15 1999
+++ gdb/gdbserver/gdbreplay.c	Sun Apr 11 19:16:26 1999
@@ -27,6 +27,7 @@
 #include <signal.h>
 #include <ctype.h>
 #include <fcntl.h>
+#include <errno.h>
 
 /* Sort of a hack... */
 #define EOL (EOF - 1)
@@ -41,20 +42,15 @@
 perror_with_name (string)
      char *string;
 {
-  extern int sys_nerr;
-  extern char *sys_errlist[];
-  extern int errno;
-  char *err;
+  char *err = strerror (errno);
   char *combined;
 
-  err = (errno < sys_nerr) ? sys_errlist[errno] : "unknown error";
   combined = (char *) alloca (strlen (err) + strlen (string) + 3);
   strcpy (combined, string);
   strcat (combined, ": ");
   strcat (combined, err);
-  fprintf (stderr, "\n%s.\n", combined);
-  fflush (stderr);
-  exit (1);
+
+  error ("%s.", combined);
 }
 
 static void
diff -u --recursive --new-file /home/phil/gdb/clean/gdb-4.17/gdb/gdbserver/utils.c gdb/gdbserver/utils.c
--- /home/phil/gdb/clean/gdb-4.17/gdb/gdbserver/utils.c	Sat Aug  9 05:49:48 1997
+++ gdb/gdbserver/utils.c	Sun Apr 11 15:34:56 1999
@@ -20,6 +20,7 @@
 #include "server.h"
 #include <stdio.h>
 #include <string.h>
+#include <errno.h>
 
 /* Generally useful subroutines used throughout the program.  */
 
@@ -31,16 +32,8 @@
 perror_with_name (string)
      char *string;
 {
-  extern int sys_nerr;
-  extern char *sys_errlist[];
-  extern int errno;
-  char *err;
+  char *err = strerror (errno);
   char *combined;
-
-  if (errno < sys_nerr)
-    err = sys_errlist[errno];
-  else
-    err = "unknown error";
 
   combined = (char *) alloca (strlen (err) + strlen (string) + 3);
   strcpy (combined, string);

function parameters regression

[Elena Zannoni]

Philippe De Muyter writes:
 > On m68k-motorola-sysv (COFF), the following tests fail, because of
 > a hp-specific new code in valops.c.
 > Can someone fix that ?  For me, testing only `using_gcc' seems too wide.
 > 
 > p t_func_values(add,func_val2)
 > You cannot use function <add> as argument.
 > You must use a pointer to function type variable. Command ignored.
 > (gdb) FAIL: gdb.base/callfuncs2.exp: p t_func_values(add,func_val2)
 > p t_func_values(func_val1,doubleit)
 > You cannot use function <doubleit> as argument.
 > You must use a pointer to function type variable. Command ignored.
 > (gdb) FAIL: gdb.base/callfuncs2.exp: p t_func_values(func_val1,doubleit)
 > p t_call_add(func_val1,3,4)
 > $48 = 7
 > (gdb) PASS: gdb.base/callfuncs2.exp: p t_call_add(func_val1,3,4)
 > p t_call_add(add,3,4)
 > You cannot use function <add> as argument.
 > You must use a pointer to function type variable. Command ignored.
 > (gdb) FAIL: gdb.base/callfuncs2.exp: p t_call_add(add,3,4)
 > 
 > Culprit code :
 >       /*elz: this code is to handle the case in which the function to be called
 >         has a pointer to function as parameter and the corresponding actual argu
 > ment
 >         is the address of a function and not a pointer to function variable.
 >         In aCC compiled code, the calls through pointers to functions (in the bo
 > dy
 >         of the function called by hand) are made via $$dyncall_external which
 >         requires some registers setting, this is taken care of if we call
 >         via a function pointer variable, but not via a function address.
 >         In cc this is not a problem. */
 > 
 >       if (using_gcc == 0)
 >         if (param_type)
 >           /* if this parameter is a pointer to function*/
 >           if (TYPE_CODE (param_type) == TYPE_CODE_PTR)
 >             if (TYPE_CODE (param_type->target_type) == TYPE_CODE_FUNC)
 >               /* elz: FIXME here should go the test about the compiler used
 >                     to compile the target. We want to issue the error
 >                     message only if the compiler used was HP's aCC.
 >                     If we used HP's cc, then there is no problem and no need
 >                     to return at this point */
 >               if (using_gcc == 0) /* && compiler == aCC*/
 >                 /* go see if the actual parameter is a variable of type
 >                 pointer to function or just a function */
 >                 if (args[i]->lval == not_lval)
 >                   {
 >                     char *arg_name;
 >                     if (find_pc_partial_function((CORE_ADDR)args[i]->aligner.con
 > tents[0], &arg_name, NULL, NULL))
 >                       error("\
 > You cannot use function <%s> as argument. \n\
 > You must use a pointer to function type variable. Command ignored.", arg_name);
 >                   }

Re: function parameters regression

[Philippe De Muyter]

> Things might have changed in the way aCC behaves now, so
> I'll investigate with HP. I'll let you know
> as soon as I hear from them.

Could you at least put in a stronger test to recognize the `aCC' compiler,
or only enable the hp-specific code when the target is hp, with a target
macro (e.g. REFUSE_FUNCTION_ADDRESS_PARAMETERS, or something like that) ?

Thanks

Philippe

Re: function parameters regression

[Elena Zannoni]

Philippe De Muyter writes:
 > > Things might have changed in the way aCC behaves now, so
 > > I'll investigate with HP. I'll let you know
 > > as soon as I hear from them.
 > 
 > Could you at least put in a stronger test to recognize the `aCC' compiler,
 > or only enable the hp-specific code when the target is hp, with a target
 > macro (e.g. REFUSE_FUNCTION_ADDRESS_PARAMETERS, or something like that) ?
 > 
 > Thanks
 > 
 > Philippe

As a general policy we try to avoid inserting ifdefs in the code if not 
absolutely necessary. 
I will wait until I know that I have no other options.
HP's debugger team is very good in providing accurate and fast answers,
so I wouldn't worry too much, it should not take too long.

Thanks for your patience in the meantime.

Elena Zannoni
Cygnus Solution

function parameters regression

[Elena Zannoni]

Philippe, 
As author of the change below (while I was working at HP), 
I'll be following up on this.
Things might have changed in the way aCC behaves now, so
I'll investigate with HP. I'll let you know
as soon as I hear from them.

Thanks

Elena Zannoni
Cygnus Solutions


Philippe De Muyter writes:
 > On m68k-motorola-sysv (COFF), the following tests fail, because of
 > a hp-specific new code in valops.c.
 > Can someone fix that ?  For me, testing only `using_gcc' seems too wide.
 > 
 > p t_func_values(add,func_val2)
 > You cannot use function <add> as argument.
 > You must use a pointer to function type variable. Command ignored.
 > (gdb) FAIL: gdb.base/callfuncs2.exp: p t_func_values(add,func_val2)
 > p t_func_values(func_val1,doubleit)
 > You cannot use function <doubleit> as argument.
 > You must use a pointer to function type variable. Command ignored.
 > (gdb) FAIL: gdb.base/callfuncs2.exp: p t_func_values(func_val1,doubleit)
 > p t_call_add(func_val1,3,4)
 > $48 = 7
 > (gdb) PASS: gdb.base/callfuncs2.exp: p t_call_add(func_val1,3,4)
 > p t_call_add(add,3,4)
 > You cannot use function <add> as argument.
 > You must use a pointer to function type variable. Command ignored.
 > (gdb) FAIL: gdb.base/callfuncs2.exp: p t_call_add(add,3,4)
 > 
 > Culprit code :
 >       /*elz: this code is to handle the case in which the function to be called
 >         has a pointer to function as parameter and the corresponding actual argu
 > ment
 >         is the address of a function and not a pointer to function variable.
 >         In aCC compiled code, the calls through pointers to functions (in the bo
 > dy
 >         of the function called by hand) are made via $$dyncall_external which
 >         requires some registers setting, this is taken care of if we call
 >         via a function pointer variable, but not via a function address.
 >         In cc this is not a problem. */
 > 
 >       if (using_gcc == 0)
 >         if (param_type)
 >           /* if this parameter is a pointer to function*/
 >           if (TYPE_CODE (param_type) == TYPE_CODE_PTR)
 >             if (TYPE_CODE (param_type->target_type) == TYPE_CODE_FUNC)
 >               /* elz: FIXME here should go the test about the compiler used
 >                     to compile the target. We want to issue the error
 >                     message only if the compiler used was HP's aCC.
 >                     If we used HP's cc, then there is no problem and no need
 >                     to return at this point */
 >               if (using_gcc == 0) /* && compiler == aCC*/
 >                 /* go see if the actual parameter is a variable of type
 >                 pointer to function or just a function */
 >                 if (args[i]->lval == not_lval)
 >                   {
 >                     char *arg_name;
 >                     if (find_pc_partial_function((CORE_ADDR)args[i]->aligner.con
 > tents[0], &arg_name, NULL, NULL))
 >                       error("\
 > You cannot use function <%s> as argument. \n\
 > You must use a pointer to function type variable. Command ignored.", arg_name);
 >                   }

Re: function parameters regression

[Philippe De Muyter]

> Things might have changed in the way aCC behaves now, so
> I'll investigate with HP. I'll let you know
> as soon as I hear from them.

Could you at least put in a stronger test to recognize the `aCC' compiler,
or only enable the hp-specific code when the target is hp, with a target
macro (e.g. REFUSE_FUNCTION_ADDRESS_PARAMETERS, or something like that) ?

Thanks

Philippe
From ezannoni@cygnus.com Mon Apr 12 16:25:00 1999
From: Elena Zannoni <ezannoni@cygnus.com>
To: gdb-patches@cygnus.com
Subject: function parameters regression
Date: Mon, 12 Apr 1999 16:25:00 -0000
Message-id: <14098.28875.852399.47907@kwikemart.cygnus.com>
References: <199904102346.BAA17978@mail.macqel.be> <199904102346.BAA17978@mail.macqel.be>
X-SW-Source: 1999-04/msg00016.html
Content-length: 2855

Philippe De Muyter writes:
 > On m68k-motorola-sysv (COFF), the following tests fail, because of
 > a hp-specific new code in valops.c.
 > Can someone fix that ?  For me, testing only `using_gcc' seems too wide.
 > 
 > p t_func_values(add,func_val2)
 > You cannot use function <add> as argument.
 > You must use a pointer to function type variable. Command ignored.
 > (gdb) FAIL: gdb.base/callfuncs2.exp: p t_func_values(add,func_val2)
 > p t_func_values(func_val1,doubleit)
 > You cannot use function <doubleit> as argument.
 > You must use a pointer to function type variable. Command ignored.
 > (gdb) FAIL: gdb.base/callfuncs2.exp: p t_func_values(func_val1,doubleit)
 > p t_call_add(func_val1,3,4)
 > $48 = 7
 > (gdb) PASS: gdb.base/callfuncs2.exp: p t_call_add(func_val1,3,4)
 > p t_call_add(add,3,4)
 > You cannot use function <add> as argument.
 > You must use a pointer to function type variable. Command ignored.
 > (gdb) FAIL: gdb.base/callfuncs2.exp: p t_call_add(add,3,4)
 > 
 > Culprit code :
 >       /*elz: this code is to handle the case in which the function to be called
 >         has a pointer to function as parameter and the corresponding actual argu
 > ment
 >         is the address of a function and not a pointer to function variable.
 >         In aCC compiled code, the calls through pointers to functions (in the bo
 > dy
 >         of the function called by hand) are made via $$dyncall_external which
 >         requires some registers setting, this is taken care of if we call
 >         via a function pointer variable, but not via a function address.
 >         In cc this is not a problem. */
 > 
 >       if (using_gcc == 0)
 >         if (param_type)
 >           /* if this parameter is a pointer to function*/
 >           if (TYPE_CODE (param_type) == TYPE_CODE_PTR)
 >             if (TYPE_CODE (param_type->target_type) == TYPE_CODE_FUNC)
 >               /* elz: FIXME here should go the test about the compiler used
 >                     to compile the target. We want to issue the error
 >                     message only if the compiler used was HP's aCC.
 >                     If we used HP's cc, then there is no problem and no need
 >                     to return at this point */
 >               if (using_gcc == 0) /* && compiler == aCC*/
 >                 /* go see if the actual parameter is a variable of type
 >                 pointer to function or just a function */
 >                 if (args[i]->lval == not_lval)
 >                   {
 >                     char *arg_name;
 >                     if (find_pc_partial_function((CORE_ADDR)args[i]->aligner.con
 > tents[0], &arg_name, NULL, NULL))
 >                       error("\
 > You cannot use function <%s> as argument. \n\
 > You must use a pointer to function type variable. Command ignored.", arg_name);
 >                   }
From ezannoni@cygnus.com Mon Apr 12 16:25:00 1999
From: Elena Zannoni <ezannoni@cygnus.com>
To: "Philippe De Muyter" <phdm@macqel.be>
Cc: ezannoni@cygnus.com (Elena Zannoni), gdb-patches@cygnus.com
Subject: Re: function parameters regression
Date: Mon, 12 Apr 1999 16:25:00 -0000
Message-id: <14098.30965.659718.60625@kwikemart.cygnus.com>
References: <14098.29249.714527.416014@kwikemart.cygnus.com> <199904122238.AAA31529@mail.macqel.be> <199904122238.AAA31529@mail.macqel.be>
X-SW-Source: 1999-04/msg00015.html
Content-length: 794

Philippe De Muyter writes:
 > > Things might have changed in the way aCC behaves now, so
 > > I'll investigate with HP. I'll let you know
 > > as soon as I hear from them.
 > 
 > Could you at least put in a stronger test to recognize the `aCC' compiler,
 > or only enable the hp-specific code when the target is hp, with a target
 > macro (e.g. REFUSE_FUNCTION_ADDRESS_PARAMETERS, or something like that) ?
 > 
 > Thanks
 > 
 > Philippe

As a general policy we try to avoid inserting ifdefs in the code if not 
absolutely necessary. 
I will wait until I know that I have no other options.
HP's debugger team is very good in providing accurate and fast answers,
so I wouldn't worry too much, it should not take too long.

Thanks for your patience in the meantime.

Elena Zannoni
Cygnus Solution
From ezannoni@cygnus.com Mon Apr 12 16:27:00 1999
From: Elena Zannoni <ezannoni@cygnus.com>
To: phdm@macqel.be, gdb-patches@cygnus.com
Subject: function parameters regression
Date: Mon, 12 Apr 1999 16:27:00 -0000
Message-id: <14098.29249.714527.416014@kwikemart.cygnus.com>
References: <199904102346.BAA17978@mail.macqel.be> <199904102346.BAA17978@mail.macqel.be>
X-SW-Source: 1999-04/msg00017.html
Content-length: 3128

Philippe, 
As author of the change below (while I was working at HP), 
I'll be following up on this.
Things might have changed in the way aCC behaves now, so
I'll investigate with HP. I'll let you know
as soon as I hear from them.

Thanks

Elena Zannoni
Cygnus Solutions


Philippe De Muyter writes:
 > On m68k-motorola-sysv (COFF), the following tests fail, because of
 > a hp-specific new code in valops.c.
 > Can someone fix that ?  For me, testing only `using_gcc' seems too wide.
 > 
 > p t_func_values(add,func_val2)
 > You cannot use function <add> as argument.
 > You must use a pointer to function type variable. Command ignored.
 > (gdb) FAIL: gdb.base/callfuncs2.exp: p t_func_values(add,func_val2)
 > p t_func_values(func_val1,doubleit)
 > You cannot use function <doubleit> as argument.
 > You must use a pointer to function type variable. Command ignored.
 > (gdb) FAIL: gdb.base/callfuncs2.exp: p t_func_values(func_val1,doubleit)
 > p t_call_add(func_val1,3,4)
 > $48 = 7
 > (gdb) PASS: gdb.base/callfuncs2.exp: p t_call_add(func_val1,3,4)
 > p t_call_add(add,3,4)
 > You cannot use function <add> as argument.
 > You must use a pointer to function type variable. Command ignored.
 > (gdb) FAIL: gdb.base/callfuncs2.exp: p t_call_add(add,3,4)
 > 
 > Culprit code :
 >       /*elz: this code is to handle the case in which the function to be called
 >         has a pointer to function as parameter and the corresponding actual argu
 > ment
 >         is the address of a function and not a pointer to function variable.
 >         In aCC compiled code, the calls through pointers to functions (in the bo
 > dy
 >         of the function called by hand) are made via $$dyncall_external which
 >         requires some registers setting, this is taken care of if we call
 >         via a function pointer variable, but not via a function address.
 >         In cc this is not a problem. */
 > 
 >       if (using_gcc == 0)
 >         if (param_type)
 >           /* if this parameter is a pointer to function*/
 >           if (TYPE_CODE (param_type) == TYPE_CODE_PTR)
 >             if (TYPE_CODE (param_type->target_type) == TYPE_CODE_FUNC)
 >               /* elz: FIXME here should go the test about the compiler used
 >                     to compile the target. We want to issue the error
 >                     message only if the compiler used was HP's aCC.
 >                     If we used HP's cc, then there is no problem and no need
 >                     to return at this point */
 >               if (using_gcc == 0) /* && compiler == aCC*/
 >                 /* go see if the actual parameter is a variable of type
 >                 pointer to function or just a function */
 >                 if (args[i]->lval == not_lval)
 >                   {
 >                     char *arg_name;
 >                     if (find_pc_partial_function((CORE_ADDR)args[i]->aligner.con
 > tents[0], &arg_name, NULL, NULL))
 >                       error("\
 > You cannot use function <%s> as argument. \n\
 > You must use a pointer to function type variable. Command ignored.", arg_name);
 >                   }
From phdm@macqel.be Mon Apr 12 17:18:00 1999
From: "Philippe De Muyter" <phdm@macqel.be>
To: gdb-patches@cygnus.com (gdb-patches@cygnus.com)
Subject: `step'-like commands in breakpoint commands list
Date: Mon, 12 Apr 1999 17:18:00 -0000
Message-id: <199904122248.AAA31605@mail.macqel.be>
X-SW-Source: 1999-04/msg00018.html
Content-length: 1050

On m68k-motorola-sysv and on powerpc-ibm-aix4.1.5.0, with gdb-4.17.87,
the testsuite fails at `continue in infrun_breakpoint_command_test', because
the breakpoint commands list is only executed up to the first `step' command.
The patch below fixes that.

Tue Apr 13 00:31:48 1999  Philippe De Muyter  <phdm@macqel.be>

	* infrun.c (clear_proceed_status): Do not set `breakpoint_proceeded'.

--- ./infrun.c	Tue Apr 13 00:30:53 1999
+++ ./infrun.c	Tue Apr 13 00:30:48 1999
@@ -783,7 +783,13 @@ clear_proceed_status ()
   stop_after_trap = 0;
   stop_soon_quietly = 0;
   proceed_to_finish = 0;
+#if 0 /* FIXME : Disabled 1999-04-12 by phdm@macqel.be, to allow `step',
+	 `next', `finish', etc. to work in breakpoint commands list.  As
+	 this is the only instruction that sets `breakpoint_proceeded',
+	 all the `breakpoint_proceeded'-related stuff could also be removed.
+	 */
   breakpoint_proceeded = 1;	/* We're about to proceed... */
+#endif
 
   /* Discard any remaining commands or status from previous stop.  */
   bpstat_clear (&stop_bpstat);
From jimb@cygnus.com Mon Apr 12 20:46:00 1999
From: Jim Blandy <jimb@cygnus.com>
To: Philip Blundell <philb@gnu.org>
Cc: gdb-patches@cygnus.com
Subject: Re: support for ARM GNU/Linux
Date: Mon, 12 Apr 1999 20:46:00 -0000
Message-id: <np90bx1a3v.fsf@zwingli.cygnus.com>
References: <E10WmL7-0006R7-00@kings-cross.london.uk.eu.org>
X-SW-Source: 1999-04/msg00019.html
Content-length: 340

> This patch adds support for GNU/Linux running on ARM systems.

Cool!  Some initial comments:

Could you adapt your patches to 4.18?  If I try to do it and anything
non-trivial comes up, I'd almost certainly screw them up.

Could you rename the native file armlinux-nat.c?  "lnx" looks like
"lynx", which is something else entirely...  :)
From pb@nexus.co.uk Tue Apr 13 07:41:00 1999
From: Philip Blundell <pb@nexus.co.uk>
To: gdb-patches@cygnus.com
Subject: Re: support for ARM GNU/Linux 
Date: Tue, 13 Apr 1999 07:41:00 -0000
Message-id: <E10X3Uv-0003Kd-00@fountain.nexus.co.uk>
References: <np90bx1a3v.fsf@zwingli.cygnus.com>
X-SW-Source: 1999-04/msg00020.html
Content-length: 19790

In message < np90bx1a3v.fsf@zwingli.cygnus.com >, Jim Blandy writes:
>Could you adapt your patches to 4.18?  If I try to do it and anything
>non-trivial comes up, I'd almost certainly screw them up.
>
>Could you rename the native file armlinux-nat.c?  "lnx" looks like
>"lynx", which is something else entirely...  :)

Sure.  I've appended here a new patch incorporating those changes.  It's 
against the 19990412 snapshot.

p.

1999-04-13  Philip Blundell  <philb@gnu.org>
	    Scott Bambrough <scottb@corelcomputer.com>

	Support for ARM GNU/Linux:
	* configure.tgt: Recognize arm*-*-linux* configuration.  Set
	cpu name to `arm' for any `arm*-*-*' configuration name.
	* configure.host: Likewise.
	* config/arm/linux.mh, config/arm/linux.mt: New files.
	* config/arm/tm-linux.h, config-arm/xm-linux.h,
	config/arm/nm-linux.h: Likewise.
	* armlinux-tdep.c, armlinux-nat.c: Likewise.

	* arm-tdep.c (ARM_LE_BREAKPOINT, ARM_BE_BREAKPOINT,
	THUMB_LE_BREAKPOINT, THUMB_BE_BREAKPOINT, LOWEST_PC,
	LITTLE_BREAKPOINT, BIG_BREAKPOINT): Move 
	definitions to...
	* config/arm/tm-arm.h: ... here.

diff -u --recursive --new-file clean/gdb-19990412/gdb/arm-tdep.c gdb-19990412/gdb/arm-tdep.c
--- clean/gdb-19990412/gdb/arm-tdep.c	Fri Apr  2 20:33:38 1999
+++ gdb-19990412/gdb/arm-tdep.c	Tue Apr 13 10:39:36 1999
@@ -61,7 +61,6 @@
      CORE_ADDR chain;
      struct frame_info *thisframe;
 {
-#define LOWEST_PC 0x20  /* the first 0x20 bytes are the trap vectors. */
   return (chain != 0 && (FRAME_SAVED_PC (thisframe) >= LOWEST_PC));
 }
 
@@ -1487,17 +1486,6 @@
   else
     return print_insn_little_arm (memaddr, info);
 }
-
-/* Sequence of bytes for breakpoint instruction.  */
-#define ARM_LE_BREAKPOINT {0xFE,0xDE,0xFF,0xE7} /* Recognized illegal opcodes */
-#define ARM_BE_BREAKPOINT {0xE7,0xFF,0xDE,0xFE} 
-#define THUMB_LE_BREAKPOINT {0xfe,0xdf}       
-#define THUMB_BE_BREAKPOINT {0xdf,0xfe}       
-
-/* The following has been superseded by BREAKPOINT_FOR_PC, but
-   is defined merely to keep mem-break.c happy.  */
-#define LITTLE_BREAKPOINT ARM_LE_BREAKPOINT
-#define BIG_BREAKPOINT    ARM_BE_BREAKPOINT
 
 /* This function implements the BREAKPOINT_FROM_PC macro.  It uses the program
    counter value to determine whether a 16- or 32-bit breakpoint should be
diff -u --recursive --new-file clean/gdb-19990412/gdb/armlinux-nat.c gdb-19990412/gdb/armlinux-nat.c
--- clean/gdb-19990412/gdb/armlinux-nat.c	Thu Jan  1 01:00:00 1970
+++ gdb-19990412/gdb/armlinux-nat.c	Tue Apr 13 12:33:12 1999
@@ -0,0 +1,148 @@
+/* ARM native support for SYSV systems (pre-SVR4).
+   Copyright (C) 1999 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.  */
+
+#include "defs.h"
+#include "inferior.h"
+#include <sys/ptrace.h>
+#include "gdbcore.h"
+#include <sys/user.h>		/* After a.out.h  */
+
+int
+arm_register_u_addr(blockend, regnum)
+     int blockend;
+     int regnum;
+{
+  return blockend + REGISTER_BYTE(regnum);  
+}
+
+int
+kernel_u_size()
+{
+  return (sizeof (struct user));
+}
+
+#ifdef HAVE_GREGSET_T
+#include <sys/procfs.h>
+
+/* Given a pointer to a general register set in /proc format
+    (gregset_t *), unpack the register contents and supply them as
+    gdb's idea of the current register values. */
+
+void
+supply_gregset (gregsetp)
+    gregset_t *gregsetp;
+{
+  int i;
+  
+  for (i = 0; i < 26; i++)
+    supply_register (i, (char *) (*gregsetp + i));
+}
+
+#endif
+
+void
+fetch_inferior_registers (regno)
+     int regno;		/* Original value discarded */
+{
+  register int i;
+  register unsigned int regaddr;
+  char buf[MAX_REGISTER_RAW_SIZE];
+
+  struct user u;
+  unsigned int offset = (char*)&u.u_ar0 - (char*)&u;
+  offset = ptrace (PT_READ_U, inferior_pid,
+		   (PTRACE_ARG3_TYPE)offset, 0) - KERNEL_U_ADDR;
+
+  registers_fetched ();
+  
+  for (regno = 0; regno < NUM_GREGS; regno++)
+    {
+      regaddr = offset + regno * sizeof(long);
+      *(int*)&buf[0] = ptrace (PT_READ_U, inferior_pid,
+			       (PTRACE_ARG3_TYPE)regaddr, 0);
+      if (regno == PC_REGNUM)
+	  *(int*)&buf[0] = GET_PC_PART (*(int*)&buf[0]);
+      supply_register (regno,buf);
+    }
+    
+  *(int*)&buf[0] = ptrace (PT_READ_U, inferior_pid,
+			   (PTRACE_ARG3_TYPE)(offset + PC_REGNUM*sizeof(long)),
+			   0);
+  supply_register (PS_REGNUM,buf); /* set virtual register ps same as pc */
+
+  /* read the floating point registers */
+  offset = (char*)&u.u_fp0 - (char *)&u;
+  *(int*)buf = ptrace (PT_READ_U, inferior_pid, (PTRACE_ARG3_TYPE)offset, 0);
+  supply_register (FPS_REGNUM,buf);
+  
+  for (regno = 16; regno < 24; regno++) {
+      regaddr = offset /* + 4 */ + 12 * (regno - 16);
+      for (i = 0; i < 12; i += sizeof(int))
+	*(int*) &buf[i] = ptrace (PT_READ_U, inferior_pid,
+				  (PTRACE_ARG3_TYPE)(regaddr + i), 0);
+      supply_register (regno,buf);
+  }
+}
+
+/* Store our register values back into the inferior.
+   If REGNO is -1, do this for all registers.
+   Otherwise, REGNO specifies which register (so we can save time).  */
+
+void
+store_inferior_registers (regno)
+     int regno;
+{
+  register unsigned int regaddr;
+  char buf[80];
+
+  struct user u;
+  unsigned long value;
+  unsigned int offset = (char *) &u.u_ar0 - (char *) &u;
+  offset = ptrace (PT_READ_U, inferior_pid, (PTRACE_ARG3_TYPE) offset, 0)
+      - KERNEL_U_ADDR;
+
+  if (regno >= 0) {
+      if (regno >= 16) return;
+      regaddr = offset + 4 * regno;
+      errno = 0;
+      value = read_register (regno);
+      if (regno == PC_REGNUM)
+	  value = SET_PC_PART (read_register (PS_REGNUM), value);
+      ptrace (PT_WRITE_U, inferior_pid, (PTRACE_ARG3_TYPE) regaddr, value);
+      if (errno != 0)
+	{
+	  sprintf (buf, "writing register number %d", regno);
+	  perror_with_name (buf);
+	}
+    }
+  else for (regno = 0; regno < 15; regno++)
+    {
+      regaddr = offset + regno * 4;
+      errno = 0;
+      value = read_register (regno);
+      if (regno == PC_REGNUM)
+	  value = SET_PC_PART (read_register (PS_REGNUM), value);
+      ptrace (6, inferior_pid, (PTRACE_ARG3_TYPE) regaddr, value);
+      if (errno != 0)
+	{
+	  sprintf (buf, "writing all regs, number %d", regno);
+	  perror_with_name (buf);
+	}
+    }
+}
diff -u --recursive --new-file clean/gdb-19990412/gdb/armlinux-tdep.c gdb-19990412/gdb/armlinux-tdep.c
--- clean/gdb-19990412/gdb/armlinux-tdep.c	Thu Jan  1 01:00:00 1970
+++ gdb-19990412/gdb/armlinux-tdep.c	Tue Apr 13 10:39:36 1999
@@ -0,0 +1,65 @@
+/* Target-dependent code for the ArmLinux, for GDB, the GNU Debugger.
+   Copyright 1988, 1989, 1991, 1992, 1993, 1995 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.  */
+
+#include "defs.h"
+#include "frame.h"
+#include "inferior.h"
+
+/* APCS (ARM procedure call standard) defines the following prologue:
+
+   mov		ip, sp
+  [stmfd	sp!, {a1,a2,a3,a4}]
+   stmfd	sp!, {...,fp,ip,lr,pc}
+  [stfe		f7, [sp, #-12]!]
+  [stfe		f6, [sp, #-12]!]
+  [stfe		f5, [sp, #-12]!]
+  [stfe		f4, [sp, #-12]!]
+   sub		fp, ip, #nn	// nn == 20 or 4 depending on second ins
+*/
+
+void
+arm_extract_return_value(type, regbuf, valbuf)
+     struct type *type;
+     char regbuf[];
+     void *valbuf;
+{
+  if (TYPE_CODE_FLT == TYPE_CODE(type))
+    convert_from_extended(regbuf + REGISTER_BYTE(F0_REGNUM), valbuf);
+  else
+    memcpy(valbuf, regbuf, TYPE_LENGTH(type));
+}
+
+/* not in generic code, macro in tm-arm.h */
+void
+arm_store_return_value(type, valbuf)
+     struct type *type;
+     void *valbuf;
+{
+  if (TYPE_CODE_FLT == TYPE_CODE(type)) {
+    char _buf[MAX_REGISTER_RAW_SIZE];
+    convert_to_extended(valbuf, _buf);
+    write_register_bytes(REGISTER_BYTE(F0_REGNUM), _buf, MAX_REGISTER_RAW_SIZE);
+  } else
+    write_register_bytes(0, valbuf, TYPE_LENGTH(type));
+}
+
+void
+_initialize_linux_tdep(void)
+{
+}
diff -u --recursive --new-file clean/gdb-19990412/gdb/config/arm/linux.mh gdb-19990412/gdb/config/arm/linux.mh
--- clean/gdb-19990412/gdb/config/arm/linux.mh	Thu Jan  1 01:00:00 1970
+++ gdb-19990412/gdb/config/arm/linux.mh	Tue Apr 13 11:24:09 1999
@@ -0,0 +1,8 @@
+# Host: ARM running GNU/Linux
+
+XM_FILE= xm-linux.h
+XDEPFILES= ser-tcp.o 
+
+NAT_FILE= nm-linux.h
+NATDEPFILES= infptrace.o solib.o inftarg.o fork-child.o corelow.o core-aout.o core-regset.o armlinux-nat.o
+GDBSERVER_DEPFILES= low-linux.o
diff -u --recursive --new-file clean/gdb-19990412/gdb/config/arm/linux.mt gdb-19990412/gdb/config/arm/linux.mt
--- clean/gdb-19990412/gdb/config/arm/linux.mt	Thu Jan  1 01:00:00 1970
+++ gdb-19990412/gdb/config/arm/linux.mt	Tue Apr 13 11:24:01 1999
@@ -0,0 +1,6 @@
+# Target: ARM running GNU/Linux with a.out and ELF
+
+TDEPFILES= armlinux-tdep.o arm-tdep.o
+TM_FILE= tm-linux.h
+
+GDBSERVER_DEPFILES= low-linux.o
diff -u --recursive --new-file clean/gdb-19990412/gdb/config/arm/nm-linux.h gdb-19990412/gdb/config/arm/nm-linux.h
--- clean/gdb-19990412/gdb/config/arm/nm-linux.h	Thu Jan  1 01:00:00 1970
+++ gdb-19990412/gdb/config/arm/nm-linux.h	Tue Apr 13 12:20:35 1999
@@ -0,0 +1,43 @@
+/* Native machine definitions for GDB on ARM running GNU/Linux
+   Copyright (C) 1999 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 NM_LINUX_H
+#define NM_LINUX_H
+
+/* Get generic SVR4 definitions.  */
+#include "nm-sysv4.h"
+
+/* Here we differ from SVR4.  */
+#undef USE_PROC_FS      
+
+/* Override copies of {fetch,store}_inferior_registers in infptrace.c.  */
+#define FETCH_INFERIOR_REGISTERS
+
+#define REGISTER_U_ADDR(addr, blockend, regno) \
+	(addr) = arm_register_u_addr ((blockend),(regno));
+
+/* Since this is a native build, we just use whatever byte order the
+   compiler has selected.  */
+#ifdef __ARMEB__
+#define HOST_BYTE_ORDER BIG_ENDIAN
+#else
+#define HOST_BYTE_ORDER LITTLE_ENDIAN
+#endif
+
+#endif /* NM_LINUX_H */
diff -u --recursive --new-file clean/gdb-19990412/gdb/config/arm/tm-arm.h gdb-19990412/gdb/config/arm/tm-arm.h
--- clean/gdb-19990412/gdb/config/arm/tm-arm.h	Fri Apr  2 20:33:39 1999
+++ gdb-19990412/gdb/config/arm/tm-arm.h	Tue Apr 13 10:39:37 1999
@@ -22,6 +22,8 @@
 struct value;
 #endif
 
+#define TARGET_ARM
+
 #define TARGET_BYTE_ORDER_SELECTABLE
 
 /* IEEE format floating point */
@@ -118,6 +120,7 @@
    that I can clear the status bits from pc (register 15) */
 
 #define NUM_REGS 26
+#define NUM_GREGS 16
 
 /* An array of names of registers. */
 
@@ -452,3 +455,16 @@
 
 #undef  IN_SIGTRAMP
 #define IN_SIGTRAMP(pc, name) 0
+
+/* Sequence of bytes for breakpoint instruction.  */
+#define ARM_LE_BREAKPOINT {0xFE,0xDE,0xFF,0xE7} /* Recognized illegal opcodes */
+#define ARM_BE_BREAKPOINT {0xE7,0xFF,0xDE,0xFE}
+#define THUMB_LE_BREAKPOINT {0xfe,0xdf}
+#define THUMB_BE_BREAKPOINT {0xdf,0xfe}
+
+/* The following has been superseded by BREAKPOINT_FOR_PC, but
+   is defined merely to keep mem-break.c happy.  */
+#define LITTLE_BREAKPOINT ARM_LE_BREAKPOINT
+#define BIG_BREAKPOINT    ARM_BE_BREAKPOINT
+
+#define LOWEST_PC 0x20  /* the first 0x20 bytes are the trap vectors. */
diff -u --recursive --new-file clean/gdb-19990412/gdb/config/arm/tm-linux.h gdb-19990412/gdb/config/arm/tm-linux.h
--- clean/gdb-19990412/gdb/config/arm/tm-linux.h	Thu Jan  1 01:00:00 1970
+++ gdb-19990412/gdb/config/arm/tm-linux.h	Tue Apr 13 13:08:40 1999
@@ -0,0 +1,94 @@
+/* Definitions to target GDB to ARM GNU/Linux
+   Copyright 1992, 1993, 1999 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__
+
+/* Scott: SHLIBLEN from bfd/riscix.c. */
+#define SHLIBLEN	60
+
+/* Offset to saved PC in sigcontext, from <linux/signal.h>.  */
+#define SIGCONTEXT_PC_OFFSET	(sizeof(unsigned long) + sizeof(long) * 15)
+
+/* Number of traps that happen between exec'ing the shell to run an
+   inferior, and when we finally get to the inferior code.  This is 2
+   on most implementations. */
+#define START_INFERIOR_TRAPS_EXPECTED	2
+
+/* The following is used in the macro CALL_DUMMY in tm-arm.h. */
+#define OS_BKPT_SWI	0xef9f0001
+
+/* Add command to set APCS_32 debugger variable.  Used to determine if 
+   32 bit or 26 bit program counter is being used. Set to 1 to add the
+   command to the debugger.  */
+#define ADD_SET_APCS_COMMAND	0
+
+/* It is unknown which, if any, SVR4 assemblers do not accept dollar signs
+   in identifiers.  The default in G++ is to use dots instead, for all SVR4
+   systems, so we make that our default also.  FIXME: There should be some
+   way to get G++ to tell us what CPLUS_MARKER it is using, perhaps by
+   stashing it in the debugging information as part of the name of an
+   invented symbol ("gcc_cplus_marker$" for example). */
+
+#undef CPLUS_MARKER
+#define CPLUS_MARKER '.'
+
+/* Include the generic ARM target header. */
+#include "arm/tm-arm.h"
+
+/* The following are used in arm_breakpoint_from_pc() in arm-tdep.c */
+#undef  ARM_LE_BREAKPOINT
+#define ARM_LE_BREAKPOINT 	  {0x01,0x00,0x9f,0xef}		/* swi 0x9f0001 */
+#undef  ARM_BE_BREAKPOINT
+#define ARM_BE_BREAKPOINT 	  {0xef,0x9f,0x00,0x01}
+
+/* This is used in the macro FRAME_CHAIN_VALID in tm-arm.h. */
+#undef  LOWEST_PC
+#define LOWEST_PC 0x8000  /* the first page is not writable in ARM Linux. */
+
+/* For SVR4 shared libraries, each call to a library routine goes through
+   a small piece of trampoline code in the ".plt" section.
+   The horribly ugly wait_for_inferior() routine uses this macro to detect
+   when we have stepped into one of these fragments.
+   We do not use lookup_solib_trampoline_symbol_by_pc, because
+   we cannot always find the shared library trampoline symbols
+   (e.g. on Irix5).  */
+extern int in_plt_section PARAMS ((CORE_ADDR, char *));
+
+/* If PC is in a shared library trampoline code, return the PC
+   where the function itself actually starts.  If not, return 0.  */
+#undef  SKIP_TRAMPOLINE_CODE
+#define SKIP_TRAMPOLINE_CODE(pc)					\
+   ((in_plt_section((pc), NULL) ? find_solib_trampoline_target (pc)	\
+		: arm_skip_stub (pc)))
+
+#undef  IN_SOLIB_CALL_TRAMPOLINE
+#define IN_SOLIB_CALL_TRAMPOLINE(pc, name) (in_plt_section((pc), (name)) \
+					    || arm_in_call_stub (pc, name))
+
+#ifndef GET_PC_PART
+#define GET_PC_PART(addr)	ADDR_BITS_REMOVE(addr)
+#endif
+
+/* This probably needs fixing to support APCS-26.  */
+#ifndef SET_PC_PART
+#define SET_PC_PART(old,new)	new
+#endif
+
+#endif  /* #ifndef TM_LINUX_H */
diff -u --recursive --new-file clean/gdb-19990412/gdb/config/arm/xm-linux.h gdb-19990412/gdb/config/arm/xm-linux.h
--- clean/gdb-19990412/gdb/config/arm/xm-linux.h	Thu Jan  1 01:00:00 1970
+++ gdb-19990412/gdb/config/arm/xm-linux.h	Tue Apr 13 10:55:56 1999
@@ -0,0 +1,36 @@
+/* Native support for Linux, for GDB, the GNU debugger.
+   Copyright (C) 1999 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 __XM_LINUX_H__
+#define __XM_LINUX_H__
+
+#include "arm/xm-arm.h"
+
+#define HAVE_TERMIOS
+
+/* This is the amount to subtract from u.u_ar0
+   to get the offset in the core file of the register values.  */
+#define KERNEL_U_ADDR		0x0
+
+#define NEED_POSIX_SETPGID
+
+/* Need R_OK etc, but USG isn't defined.  */
+#include <unistd.h>
+
+#endif	/* __XM_LINUX_H__ */
diff -u --recursive --new-file clean/gdb-19990412/gdb/configure.host gdb-19990412/gdb/configure.host
--- clean/gdb-19990412/gdb/configure.host	Thu Mar 25 01:27:49 1999
+++ gdb-19990412/gdb/configure.host	Tue Apr 13 10:39:37 1999
@@ -11,6 +11,7 @@
 case "${host_cpu}" in
 
 alpha*)			gdb_host_cpu=alpha ;;
+arm*)			gdb_host_cpu=arm ;;
 c[12])			gdb_host_cpu=convex ;;
 hppa*)			gdb_host_cpu=pa ;;
 i[3456]86*)		gdb_host_cpu=i386 ;;
@@ -35,6 +36,7 @@
 alpha*-*-osf[3456789]*)	gdb_host=alpha-osf3 ;;
 alpha*-*-linux*)	gdb_host=alpha-linux ;;
 
+arm*-*-linux*)		gdb_host=linux ;;
 arm-*-*)		gdb_host=arm ;;
 
 c[12]-*-*)		gdb_host=convex ;;
diff -u --recursive --new-file clean/gdb-19990412/gdb/configure.tgt gdb-19990412/gdb/configure.tgt
--- clean/gdb-19990412/gdb/configure.tgt	Tue Apr 13 01:49:52 1999
+++ gdb-19990412/gdb/configure.tgt	Tue Apr 13 10:39:37 1999
@@ -13,6 +13,7 @@
 case "${target_cpu}" in
 
 alpha*)			gdb_target_cpu=alpha ;;
+arm*)			gdb_target_cpu=arm ;;
 c[12])			gdb_target_cpu=convex ;;
 hppa*)			gdb_target_cpu=pa ;;
 i[3456]86*)		gdb_target_cpu=i386 ;;
@@ -50,6 +51,8 @@
 
 arc-*-*)		gdb_target=arc ;;
 
+arm*-*-linux*)		gdb_target=linux 
+		configdirs="${configdirs} gdbserver" ;;
 arm-*-* | thumb-*-* | strongarm-*-*)	gdb_target=arm
 
 			# rdi doesn't work for wingdb yet