From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30604 invoked by alias); 21 Apr 2014 23:56:40 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 30594 invoked by uid 89); 21 Apr 2014 23:56:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-pa0-f74.google.com Received: from mail-pa0-f74.google.com (HELO mail-pa0-f74.google.com) (209.85.220.74) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 21 Apr 2014 23:56:39 +0000 Received: by mail-pa0-f74.google.com with SMTP id fb1so623384pad.5 for ; Mon, 21 Apr 2014 16:56:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:content-type :content-transfer-encoding:message-id:date:to:cc:subject:in-reply-to :references; bh=vtq+glYszdhvVksc5CtXVDdxJKmxK4N92XRMrGlKFNw=; b=QMGWRMtb6GkBsJ5bvpXDYPsg+KshW+bp+wDs7nTsupnh/CK1ns77YcxLjaQ7cpy9kE D4ddtH/D1LyT27JyA9tdA9EnbNjCKHB4uZpc6kZLyN6S/R0zl4TXPNQQHPa4Fb0fdgED gjnd3LXvONW5VYPvD7hPlTiOj1iNOWOgvH7N+qs0+cujtQJZOHMG/7QmdAq8fa5kKAhY JR4rOLNwaaYeOfWMcEZCd5hw1WbwJRIy8wxbIxpDposdJ1W/Hr+av8P5yAqGqoIP11pb PLv8gNW3X9PgiCkR+BileY+BU/e3lnhT6pN26hcz38+Z6kRD97qXB8ZeedyR/AZM8kHA EcKA== X-Gm-Message-State: ALoCoQmKD42l64ixH54bSUbIVP+OUsWUjUstBlXJu4AaMCic1hUt/oY1YBr24p8VZNqki/X6S9Fc25irfcM+ahfi0yI8kBneWjjfUMhF5ZKqUVyApuoEJblaqrqkoq1jksS83xnAYX0+WG23tgVUbxUb6gpB7HXfnDXyNL5Nfqr095j3oprOCA2EoWldfllSSQ0Cdqrf0Cae6z/FXWxFtw+pYxGJGzgG/Q== X-Received: by 10.66.145.105 with SMTP id st9mr22799413pab.23.1398124597522; Mon, 21 Apr 2014 16:56:37 -0700 (PDT) Received: from corp2gmr1-2.hot.corp.google.com (corp2gmr1-2.hot.corp.google.com [172.24.189.93]) by gmr-mx.google.com with ESMTPS id a44si5386100yhb.6.2014.04.21.16.56.37 for (version=TLSv1.1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 21 Apr 2014 16:56:37 -0700 (PDT) Received: from ruffy.mtv.corp.google.com (ruffy.mtv.corp.google.com [172.17.128.44]) by corp2gmr1-2.hot.corp.google.com (Postfix) with ESMTP id EE8E75A4121; Mon, 21 Apr 2014 16:56:36 -0700 (PDT) From: Doug Evans MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21333.45108.381336.447391@ruffy.mtv.corp.google.com> Date: Mon, 21 Apr 2014 23:56:00 -0000 To: Siva Chandra Cc: gdb-patches Subject: Re: [PATCH v14 3/4] Add support for lookup, overload resolution and invocation of C++ debug methods In-Reply-To: References: X-IsSubscribed: yes X-SW-Source: 2014-04/txt/msg00422.txt.bz2 Siva Chandra writes: > Attached is the v14 of this part of the patch series. This version > addresses a concern raised by Doug during his v12/v13 review. Hi. I've been playing with the patch set a bit. Another issue I have is this bit of code in, e.g., value_x_binop: value_user_defined_op (&arg1, argvec + 1, tstr, &static_memfuncp, 2, &argvec[0], &dm_worker); if (argvec[0]) { if (static_memfuncp) { argvec[1] = argvec[0]; argvec++; } if (noside == EVAL_AVOID_SIDE_EFFECTS) { struct type *return_type; return_type = TYPE_TARGET_TYPE (check_typedef (value_type (argvec[0]))); return value_zero (return_type, VALUE_LVAL (arg1)); } return call_function_by_hand (argvec[0], 2 - static_memfuncp, argvec + 1); } if (dm_worker != NULL) { struct cleanup *dm_worker_cleanup = make_cleanup (xfree, dm_worker); struct value *ret_val = invoke_debug_method (dm_worker, arg1, &arg2, 1); do_cleanups (dm_worker_cleanup); return ret_val; } Does this mean we call the debug method (assuming it wins) for the case of noside == EVAL_AVOID_SIDE_EFFECTS? Here and elsewhere there's logic that the debug method code is not being included in, and it makes me want to do things differently. Fortunately, I think (though I haven't implemented it) it won't be hard. Just like we have TYPE_CODE_INTERNAL_FUNCTION we could also have TYPE_CODE_EXTERNAL_FUNCTION, and use that to make debug methods less special case. clone_debug_method_worker could return a struct value that is a TYPE_CODE_EXTERNAL_FUNCTION, and then just before the call to call_function_by_hand that would happen for normal methods, we'd have a check for TYPE_CODE_EXTERNAL_FUNCTION and call call_debug_method instead. This would be akin to this code in eval.c: 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); return call_function_by_hand (argvec[0], nargs, argvec + 1); [I know the function to do this is currently named invoke_debug_method but Consistency Is Good makes me want to have: call_function_by_hand, call_internal_function, and call_debug_method instead of: call_function_by_hand, call_internal_function, and invoke_debug_method.] This might(!) then let us remove the dm_worker arg to find_overload_match. If a debug method is found *valp is a TYPE_CODE_EXTERNAL_FUNCTION instead of a TYPE_CODE_FUNC. Thoughts?