Re: [PATCH 3/4 v15] Add support for lookup, overload resolution and invocation of C++ xmethod (was debug methods)

[Doug Evans <dje at google dot com>]

Siva Chandra writes:
 > On Tue, May 13, 2014 at 2:06 PM, Doug Evans <dje@google.com> wrote:
 > > Siva Chandra writes:
 > >  > As explained in the posting of 2/4, the changes in this part from v14
 > >  > are the name and that find_overload_match returns the matching xmethod
 > >  > as a TYPE_CODE_XMETHOD value.
 > >  >
 > >  > The 2/4 posting: https://sourceware.org/ml/gdb-patches/2014-04/msg00585.html
 > >  >
 > >  > ChangeLog
 > >  > 2014-04-28  Siva Chandra Reddy  <sivachandra@google.com>
 > >  >
 > >  >         * eval.c (evaluate_subexp_standard): Call the xmethod if the
 > >  >         best match method returned by find_overload_match is an xmethod.
 > >  >         * valarith.c (value_x_binop, value_x_unop): Call the xmethod if
 > >  >         the best matching operator returned by find_overload_match is an
 > >  >         xmethod.
 > >  >         * valops.c: #include "extension.h".
 > >  >         (find_method_list): Add "fn_list" and "dm_worker_vec" arguments.
 > >  >         Return void.  The list of matching source methods is returned in
 > >  >         "fn_list" and a vector of matching debug method workers is
 > >  >         returned in "dm_worker_vec".  Update all callers.
 > >  >         (value_find_oload_method_list): Likewise.
 > >  >         (find_oload_champ): Add "dm_worker_vec" parameter.  If it is
 > >  >         non-NULL, then the index of the best matching method in this
 > >  >         vector is returned.  Update all callers.
 > >  >         (find_overload_match): Include xmethods while performing overload
 > >  >         resolution.
 > >  >         (value_has_indirect_dynamic_type, cast_args_to_param_types,
 > >  >         equal_param_types_p, derived_hides_base_method): New functions.
 > >  > diff --git a/gdb/eval.c b/gdb/eval.c
 > >  > index 3e62ead..c9f402b 100644
 > >  > --- a/gdb/eval.c
 > >  > +++ b/gdb/eval.c
 > >  > @@ -1758,11 +1758,25 @@ evaluate_subexp_standard (struct type *expect_type,
 > >  >          error (_("Expression of type other than "
 > >  >                   "\"Function returning ...\" used as function"));
 > >  >      }
 > >  > -      if (TYPE_CODE (value_type (argvec[0])) == TYPE_CODE_INTERNAL_FUNCTION)
 > >  > -    return call_internal_function (exp->gdbarch, exp->language_defn,
 > >  > -                                   argvec[0], nargs, argvec + 1);
 > >  > +      switch (TYPE_CODE (value_type (argvec[0])))
 > >  > +    {
 > >  > +    case TYPE_CODE_INTERNAL_FUNCTION:
 > >  > +      return call_internal_function (exp->gdbarch, exp->language_defn,
 > >  > +                                     argvec[0], nargs, argvec + 1);
 > >  > +    case TYPE_CODE_XMETHOD:
 > >  > +      {
 > >  > +        struct value *retval;
 > >  > +        struct cleanup *xm_cleanup;
 > >  > +
 > >  > +        xm_cleanup = make_cleanup (free_xmethod_value, argvec[0]);
 > >  > +        retval = call_xmethod (argvec[0], nargs, argvec + 1);
 > >  > +        do_cleanups (xm_cleanup);
 > >  >
 > >  > -      return call_function_by_hand (argvec[0], nargs, argvec + 1);
 > >  > +        return retval;
 > >  > +      }
 > >  > +    default:
 > >  > +      return call_function_by_hand (argvec[0], nargs, argvec + 1);
 > >  > +    }
 > >  >        /* pai: FIXME save value from call_function_by_hand, then adjust
 > >  >       pc by adjust_fn_pc if +ve.  */
 > >  >
 > >
 > > Hi.
 > > I wonder if we could simplify some code by having a wrapper function
 > > to call_internal_function, call_xmethod, call_function_by_hand.
 > > The above code would be put into this function, and
 > > evaluate_subexp_standard would just call this function.
 > > I'm hoping it could be used everywhere you add calls to call_xmethod.
 > 
 > I agree that it would be nice to have a wrapper function with all
 > kinds of calls going out from that one function. But,
 > call_internal_function takes gdbarch and lang arguments which
 > call_xmethod and call_function_by_hand do not. As it stands with this
 > patch today, call_xmethod and call_function_by hand are called from
 > evaluate_subexp_standard, value_x_binop and value_x_unop. The latter
 > two functions do not take arch and lang arguments and are called from
 > multiple places. Do we want to add arch and lang arguments to these
 > functions just so that we can have a wrapper function? Or, is a static
 > wrapper function in eval.c good enough just for use in
 > evaluate_subexp_standard?
 > 
 > Thanks,
 > Siva Chandra

Heh.  I'll bet the arch/language arguments are in call_internal_function
because of python (since that's what is passed to ensure_python_env).
So now I'm wondering where the python invoke_xmethod support gets its
gdbarch from.  Have to check the python patch.

[Plus I'd bet good money that although value_x_binop, value_x_unop
don't take arch/language arguments, they still need them.  :-)
But no matter, just wondering.]

Ok, let's skip the wrapper, at least for now.