From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30130 invoked by alias); 16 Nov 2013 00:05:53 -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 30118 invoked by uid 89); 16 Nov 2013 00:05:52 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_40,RDNS_NONE,SPF_PASS autolearn=no version=3.3.2 X-HELO: mail-vb0-f42.google.com Received: from Unknown (HELO mail-vb0-f42.google.com) (209.85.212.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Sat, 16 Nov 2013 00:05:51 +0000 Received: by mail-vb0-f42.google.com with SMTP id p14so3283133vbm.1 for ; Fri, 15 Nov 2013 16:05:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=4qcy1W/uz1DvdYsWAe6EVMdJN0MFHYOuQo+GKrO2+5k=; b=YwgViHEbsm/VC1TG7Jdra0bNcRrSUAORWGCdPkh+fNj/Jz3MG3a/jTutEsIrUdBq5j O5oJowErK7nK63sGZI2VqeH/dWrTvmA2s3CsPpCDsE6zshpTeQhU5Kvcnoeng0RyNMQv 1/WU6JtQTaO5MMpOXlfjLSeDjHRleyj4WQkaDGR/q1EgFx6RCQIj0BFkT8PsUpDH4rw7 7QFl3bsffkCdHti7rptVjgUYlxIlduBRUbMAicBEG+O0WkZ0sbnqtJvjAyjiqwFRqdQv k/EwFjQrwfVj27yhmRnBBRrUJ5ynDGYNfF4tsfiTYtRGsob84dEjZpMo/ZMrhuhpeoFD +iWw== X-Gm-Message-State: ALoCoQn3yhh/IhwXtbj27pixUdGBMxPknuBnIlmqAt6UlEeHiJLfQ2LS7zmbttezT/RlFFU2TchbqkAbq5rs1Dggfqs3g5vqmWZ/s21wsdwh7akNsgIboYRX7uyWFpoPD0jmwNj61UUQUm5AgYrPKgpt5/HSIs9RySmHBpEu9ERL36sPOMzbg/YTOHJdsp/HHicsMC+apZFFVqBn5MPo6r0HK+qqsQd4Fg== MIME-Version: 1.0 X-Received: by 10.220.64.69 with SMTP id d5mr5876998vci.11.1384560343134; Fri, 15 Nov 2013 16:05:43 -0800 (PST) Received: by 10.52.237.232 with HTTP; Fri, 15 Nov 2013 16:05:42 -0800 (PST) In-Reply-To: References: <87r4hefx59.fsf@fleche.redhat.com> <871u995pbt.fsf@fleche.redhat.com> <87ehaq5nkr.fsf@fleche.redhat.com> <87txfds4vf.fsf@fleche.redhat.com> Date: Sat, 16 Nov 2013 00:54:00 -0000 Message-ID: Subject: Re: [RFC] Debug Methods in GDB Python From: Doug Evans To: Siva Chandra Cc: Tom Tromey , gdb-patches Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes X-SW-Source: 2013-11/txt/msg00433.txt.bz2 On Fri, Nov 15, 2013 at 2:27 PM, Siva Chandra wrote: > Thanks a lot for reviewing. > > On Fri, Nov 15, 2013 at 1:59 PM, Tom Tromey wrote: > >> I can do that if you want; but meanwhile I think if you wrote the >> tests... > > Yes. Now that you are OK with the general approach, I am going to > write the tests and elaborate the docs. Will send out patches for > these early next week. > >> Also I was curious if this supports operator overloading. Like can I >> define an "operator+"? > > Yes. Operator overloading is handled the same way as methods. The > operator functions have to be methods though. > >> Siva> + if (ext_fnp) >> Siva> + { >> Siva> + if (ext_fn_is_method (ext_fnp)) >> Siva> + { >> Siva> + struct value *ret_val; >> Siva> + >> Siva> + ret_val = ext_fn_invoke_method (ext_fnp, arg2, argvec + 2, >> Siva> + nargs - 1); >> Siva> + if (ret_val == NULL) >> Siva> + error (_("Error invoking debug method for method %s."), >> Siva> + tstr); >> Siva> + >> Siva> + return ret_val; >> Siva> + } >> Siva> + } >> >> What happens here if "ext_fnp && !ext_fn_is_method"? > >> Siva> +struct py_ext_object >> Siva> +{ >> Siva> + /* Holds an instance of the DebugMethod class. */ >> Siva> + PyObject *object; >> Siva> + >> Siva> + /* Holds the type of the 'this' object. */ >> Siva> + PyObject *match_py_obj_type; >> Siva> + >> Siva> + /* Holds the matching method name. */ >> Siva> + const char *match_method; >> >> How "match_method" is allocated and how its lifetime is managed is >> really unclear to me. > > I will address the above two question in the next round of review. Hi. It's great that you're getting back at this. I have a few thoughts, nothing burdensome I hope, in random order It would be good to provide enable/disable/info support akin the the python pretty-printers. The original pretty-printers used regexps for matching but that was IIUC found to be excessively general. We might want to avoid them in the basic versions of debug methods. I could be wrong but it seemed like errors were handled differently than in the pretty-printers. The inconsistency doesn't feel warranted. IIRC the "ext_lang" stuff was going to be deleted, right? I wonder if other users are going to constantly trip on the name "debug methods" like I do. I don't have a better name at the moment, but maybe something to think about. What are debug method groups for? One thought I had, and this is mostly for discussion's sake, is why stop at providing support for user-defined methods (incl. operators)? Why not allow anything that might be "hand called" to be implemented in Python? [One way of implementing user-defined methods/operators was to translate, e.g. my_stl_vector[3], into a "pseudo- hand call", and then call into Python at the point where we would have hand-called the inferior instead.] TIA [and thanks again for getting back to this!]