This is the mail archive of the gdb@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]

Re: Problem with Nov 21 1997 valops.c:call_function_by_hand change


The suggested change is certainly not an optimal one, but it gets rid
of the mentioned regressions, and still adresses the issues of PR 13380.

A proper long term fix might be to add C++ reference handling (and perhaps
other things handled by value_arg_coerce) to the prototype case, use
value_cast, and then add a second stage of target ABI dependent integer
(and perhaps float) conversions to meet the calling conventions of the
target.
The second stage could be performed for the non-prototype case as well.

This approach might require additions to all tm files though, so we should
perhaps delay that change until we encounter a target ABI which doesn't
pass small integers as int-sized values.

Here is a more detailed description of case 2):

The testcase has the following prototype:

t_small_values (char arg1, short arg2, int arg3, char arg4, short arg5,
		char arg6, short arg7, int arg8, short arg9, short arg10)

TYPE_FLAG_PROTOTYPED gets correctly set, and the compiler is putting out the
argument types as char, short etc.

The testsuite then issues a

p t_small_values(1,2,3,4,5,6,7,8,9,10)

With your change, value_cast changes the passed in integer types according
to the prototype to char, short etc.

For the i*86 target, PUSH_ARGUMENTS is not defined, so later on value_push
is called with the type lengths of char, short etc. and pushes values which
are smaller than an int.

_But_ the i*86 calling conventions require that integer arguments are always
extended to the size of an int before being pushed on the stack.
In previous versions of GDB this requirement was met via value_arg_coerce.


> >This change:
> >
> >Fri Nov 21 19:43:23 1997  Jim Blandy  <jimb@zwingli.cygnus.com>
> >
> >	* 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.

-- 
Peter Schauer			pes@regent.e-technik.tu-muenchen.de