This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA] [4/5] Use DWARF-2 DW_AT_artificial information
Jim Blandy writes:
>
> Possibly clueless suggestion:
>
I think this is where Daniel was headed, he's the one that added that
'artificial' member. Except he ran into an HP merge roadblock.
Elena
> Couldn't we represent a method's arguments the same way we represent a
> function's arguments? That is, nfields would carry the number of
> arguments, and fields[i] would describe the n'th field. We could use
> the `artificial' member of `union field_location' in `struct field' to
> hold the information conveyed by DW_AT_artificial.
>
> The fact that we've distinguished these has caused problems in the
> past. Check out the following code in hand_function_call:
>
> for (i = nargs - 1; i >= 0; i--)
> {
> /* Assume that methods are always prototyped, unless they are off the
> end (which we should only be allowing if there is a ``...'').
> FIXME. */
> if (TYPE_CODE (ftype) == TYPE_CODE_METHOD)
> {
> if (i < n_method_args)
> args[i] = value_arg_coerce (args[i], TYPE_ARG_TYPES (ftype)[i], 1);
> else
> args[i] = value_arg_coerce (args[i], NULL, 0);
> }
>
> /* If we're off the end of the known arguments, do the standard
> promotions. FIXME: if we had a prototype, this should only
> be allowed if ... were present. */
> if (i >= TYPE_NFIELDS (ftype))
> args[i] = value_arg_coerce (args[i], NULL, 0);
>
> else
> {
> param_type = TYPE_FIELD_TYPE (ftype, i);
> args[i] = value_arg_coerce (args[i], param_type, TYPE_PROTOTYPED (ftype));
> }
>
> Those two loops could be re-collapsed into one.