This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[PATCH v14 3/4] Add support for lookup, overload resolution and invocation of C++ debug methods


Attached is the v14 of this part of the patch series. This version
addresses a concern raised by Doug during his v12/v13 review.

v13 posting: https://sourceware.org/ml/gdb-patches/2014-04/msg00147.html
Doug's comment: https://sourceware.org/ml/gdb-patches/2014-04/msg00229.html

Doug's example:

class base
{
 public:
  virtual int foo (char x) { return x + 1; }
};

class derived : public base
{
 public:
  int foo (char x) { return x + 2; }
  int foo (int x) { return x + 3; }
};

base* ptr = new derived;

Doug's concern:
Suppose we have a debug method for derived::foo (int) and none for
base::foo(char) or derived::foo(char). If I do "p ptr->foo (3)" in
gdb, which method (c++ or debug) should be invoked?

I think, since the invocation happens via the vtable, the foo (char)
version of the derived class should be invoked. My v12/v13 would have
got it wrong. When we do "p ptr->foo(3)", the number 3 is interpreted
to be an int. Consequently, when we perform an overload resolution on
the derived type, GDB would have picked the foo (int) version. To
avoid this, in the attached v14, I have modified to do this:

When (recursively) calling find_overload_match on the dynamic type
object, cast the matching virtual function arguments to the function's
param types explicitly. This way, when overload resolution is
performed on the derived type, the correct function is selected.

Doug's example also made me think of method hiding. If in the same
example above, the derived class did not have foo (char) overridden,
then its foo (int) version hides the base class foo (char) method. In
such cases, we should not look for matching debug methods on the
dynamic type. The attached v14 addresses this also.

2014-04-15  Siva Chandra Reddy  <sivachandra@google.com>

        * eval.c: #include "extension.h".
        (evaluate_subexp_standard): Lookup and invoke C++ methods defined
        in extension languages.
        * valarith.c: #include "extension.h".
        (value_user_defined_cpp_op): Add "src_fn" and "dm_worker"
        arguments.  Return void.  A source match is returned in "src_fn",
        and a debug method match is returned in "dm_worker".
        (value_user_defined_op): Likewise.
        (value_x_binop, value_x_unop): Lookup and invoke
        overloaded operator methods defined in extension languages.
        * 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".
        (value_find_oload_method_list): Likewise.
        (find_overload_match): Add "dm_worker" parameter.  If the best
        method match is a debug method, then it is returned in
        "dm_worker".  All callers updated.
        (find_oload_champ): Add "dm_worker_vec" argument.  If a caller
        wants to find the champion among a set of debug methods, then it
        has to pass the debug methods in "dm_worker_vec".  All callers
        updated.
        (value_has_indirect_dynamic_type, cast_args_to_param_types,
        equal_param_types_p, derived_hides_base_method): New functions.
        * value.h (find_overload_match): Update signature.

Attachment: dm_cpp_v14.txt
Description: Text document


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