From: Elena Zannoni <ezannoni@cygnus.com>
To: gdb-patches@cygnus.com
Subject: function parameters regression
Date: Mon, 12 Apr 1999 15:17:00 -0000 [thread overview]
Message-ID: <14098.28875.852399.47907@kwikemart.cygnus.com> (raw)
In-Reply-To: <199904102346.BAA17978@mail.macqel.be>
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);
> }
next prev parent reply other threads:[~1999-04-12 15:17 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-04-10 16:46 Philippe De Muyter
1999-04-10 17:40 ` Philippe De Muyter
1999-04-12 15:17 ` Elena Zannoni [this message]
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=14098.28875.852399.47907@kwikemart.cygnus.com \
--to=ezannoni@cygnus.com \
--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