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