Problem with Nov 21 1997 valops.c:call_function_by_hand change

Jim Blandy
Mon May 11 11:49:00 GMT 1998

>This change:
>Fri Nov 21 19:43:23 1997  Jim Blandy  <>
>	* valops.c (call_function_by_hand): If the function has a
>	prototype, convert its arguments as if by assignment.  Otherwise,
>	do the usual promotions. 
>causes at least two problems.

For reference, I made that change for PR 13380.

Since value_arg_coerce's entire job is to get coercions for function
arguments right, your approach looks essentially correct, and
certainly better than mine.  If there is a bug, the fix belongs in
value_arg_coerce or in the code which calls it.

Your change causes minimal disturbance, and fixes the PR without
introducing other problems, but I'm not sure it is the right thing.
And I do mean "not sure."

I used value_cast because I wanted to correctly pass arguments to
prototyped functions whose formal parameters had small integer types.
The present logic in value_arg_coerce always widens everything to an
int.  (ANSI C says no promotion should take place, but this isn't a
standards issue, it's an ABI issue.)  Do all ABI's really specify that
small integer arguments are always passed as int-sized values?

I guess I don't understand your second point:

>2) When using dwarf2 debugging info under Linux (via -ggdb) for the
>  gdb/testsuite/gdb.base/callfuncs.c testcase, t_small_values gets
>  TYPE_FLAG_PROTOTYPED set, and the argument types are the non-promoted
>  types.
>  value_cast then changes the passed integer arguments to char/short
>  arguments, causing misplaced arguments on the stack, as the default
>  promotion to int via value_arg_coerce is missing now.

Does this happen in the NO_PROTOTYPES case, or the prototyped case?
If the former, then the bug is that TYPE_FLAG_PROTOTYPED should only
be set when the function has a type that includes a prototype.  If the
latter, then that means that even prototyped functions expect
int-promoted arguments, which is a real surprise to me.

I don't object to your change, but I would very much like to
understand the above issues better.

More information about the Gdb mailing list