Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "Philippe De Muyter" <phdm@macqel.be>
To: gdb-patches@cygnus.com (gdb-patches@cygnus.com)
Subject: function parameters regression
Date: Sat, 10 Apr 1999 16:46:00 -0000	[thread overview]
Message-ID: <199904102346.BAA17978@mail.macqel.be> (raw)

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);
                  }


WARNING: multiple messages have this Message-ID
From: "Philippe De Muyter" <phdm@macqel.be>
To: gdb-patches@cygnus.com (gdb-patches@cygnus.com)
Subject: function parameters regression
Date: Sat, 10 Apr 1999 17:40:00 -0000	[thread overview]
Message-ID: <199904102346.BAA17978@mail.macqel.be> (raw)
Message-ID: <19990410174000.Y-iQuoc56RqFiUKQ3ChKMwe0SXqq-9JW7jG1SQNI_Fw@z> (raw)

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);



             reply	other threads:[~1999-04-10 16:46 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-04-10 16:46 Philippe De Muyter [this message]
1999-04-10 17:40 ` Philippe De Muyter
1999-04-12 15:17 ` Elena Zannoni
1999-04-12 15:51 ` Elena Zannoni
1999-04-12 16:25   ` Philippe De Muyter
1999-04-12 15:38     ` Philippe De Muyter
1999-04-12 15:51     ` Elena Zannoni

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=199904102346.BAA17978@mail.macqel.be \
    --to=phdm@macqel.be \
    --cc=gdb-patches@cygnus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox