Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Elena Zannoni <ezannoni@cygnus.com>
To: phdm@macqel.be, gdb-patches@cygnus.com
Subject: function parameters regression
Date: Mon, 12 Apr 1999 15:51:00 -0000	[thread overview]
Message-ID: <14098.29249.714527.416014@kwikemart.cygnus.com> (raw)
In-Reply-To: <199904102346.BAA17978@mail.macqel.be>

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


  parent reply	other threads:[~1999-04-12 15:51 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
1999-04-12 15:51 ` Elena Zannoni [this message]
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.29249.714527.416014@kwikemart.cygnus.com \
    --to=ezannoni@cygnus.com \
    --cc=gdb-patches@cygnus.com \
    --cc=phdm@macqel.be \
    /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