From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20120 invoked by alias); 19 Nov 2013 23:43:34 -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 20096 invoked by uid 89); 19 Nov 2013 23:43:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_50,RDNS_NONE,SPF_PASS autolearn=no version=3.3.2 X-HELO: mail-ve0-f182.google.com Received: from Unknown (HELO mail-ve0-f182.google.com) (209.85.128.182) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 19 Nov 2013 23:42:07 +0000 Received: by mail-ve0-f182.google.com with SMTP id pa12so6834174veb.13 for ; Tue, 19 Nov 2013 15:41:59 -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=Hp5w0nPHJc86QYoMcRgwKx8fTOY5HLRQlbLI7t1E6B4=; b=BtMpMH7KhoJb1lnVXJhmEvhLbx6Y0naYuCfewSwZzi/3bwJ0NafJx+4BAxyqRznTlk vH32bCg2wdofJhJYPNozvK7LA5KaB+cfznIDNE42y5eiN/gLTgD+ZbtEUA4G/7hi8ODT AgjaKiG5XZZists74AjiUrcx1RvgAJR4pVUIKCxHH93Uc23PMxPbeuVDkfTE1pvpf7qx CHUMqAKWgj4DrnmHGlY716ZnaGN0MdNv+bTcfetZ9FGrIADMJpBR6PgI36TcygwMb3bp /V26DncsJ2/L8RtIDXy0PCAoDUrHvpg2wMP08JwpI97EJdZugKSiRdT+Pp9rxWHpD1vq sUfw== X-Gm-Message-State: ALoCoQmpt4YTzdne7tT7UOPhsGbjCcRbbFkvFigd69euS2AYK4CU93a/RfReBPOmwdZFlgUupflTdo3HoiaS9I8crJKMTORmlwEDe3gl3kGTE/alPt1BgP/krbKDzrYZvw9w5+SFyCyj3W96vksJ44O1/l4GZwgSoPH+8WkMUFJLe0Uyql+m5TMQojWGAuj/7/RDk5OiFMOkMoYnvbj+eIObWLmfFrzLCA== MIME-Version: 1.0 X-Received: by 10.58.11.73 with SMTP id o9mr23385564veb.8.1384904518906; Tue, 19 Nov 2013 15:41:58 -0800 (PST) Received: by 10.52.163.52 with HTTP; Tue, 19 Nov 2013 15:41:58 -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: Tue, 19 Nov 2013 23:52: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/msg00567.txt.bz2 On Fri, Nov 15, 2013 at 4:53 PM, Siva Chandra wrote: > On Fri, Nov 15, 2013 at 4:05 PM, Doug Evans wrote: >> It would be good to provide enable/disable/info support akin the the >> python pretty-printers. > > Yes. I am planning to bring them in the next version of the patches. > >> 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. > > Do you have an alternate approach in mind? For matching the class I would look into how the current version of the libstdc++ pretty-printers do this. http://gcc.gnu.org/viewcvs/gcc/trunk/libstdc%2B%2B-v3/python/libstdcxx/v6/printers.py I don't know if that's the best way to handle debug methods, but doing something different requires a compelling reason. For matching on the method, I would just use a string comparison. Again, this is for the simple version. IIUC the API allows for more complex mechanisms, but for the start I'd say start small with something simple. [I can imagine an issue arising with operators, e.g., "operator ()" vs "operator()" or some such. Is handling that with a regexp the best way to go? Dunno.] >> I could be wrong but it seemed like errors were handled differently >> than in the pretty-printers. >> The inconsistency doesn't feel warranted. > > Yes, there is a difference. > >> IIRC the "ext_lang" stuff was going to be deleted, right? > > I am not sure. Tom had a comment long time back on this, but his > latest review said that his comments on this might be irrelevant now. > I have renamed some of the pieces related to this in my last patch. Do > you have any specific comments? The name is a tad confusing, though I'm warming up to it. The high order bit for me is you're really just abstracting away a subset of a much bigger problem space: The abstraction of all calls from gdb-proper to the extension language. >> What are debug method groups for? > > They are for disabling and enabling a group of debug methods. For > example, they could be used for debugging the debug methods themselves > or writing tests for them: You can disable a group at once instead of > disabling individually. Ah. The python pretty-printers support this differently. Again, I think there needs to be a compelling reason to do it differently. For example, note how grouping is handled there. IWBN if the user commands for enable/disable/info were as consistent as possible between the two. >> 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? > > I think that could be a fairly straightforward extension. Do you want > it to be done together with this work? Naw, I don't want to delay this work by adding more features. OTOH, I do think there is value to at least thinking about the future and not making extending what's there now harder than it otherwise could have been (to the extent that one can reasonably reason about such things without delaying the implementation forever). >> [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.] > > IIRC, you had suggested similar ideas earlier as well. However, I have > not gone that route because I thought debug methods/functions should > go through the method/function matching infrastructure. Am I missing > something here? My thought was that they *would* go through the method/function matching infrastructure, and out of that would be an appropriately crafted "hand call". It's not critical though. --- One thing I noticed in the patch is an assumption of an initial "this" pointer. While it doesn't have to be implemented today, I think we should at least know *how* it will be handled in the API, and that is, e.g., static methods where there is no "this". APIs are harder to change than implementations.