This is the mail archive of the gdb-patches@sourceware.cygnus.com mailing list for the GDB project. See the GDB home page for more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

function parameters regression




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