From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31611 invoked by alias); 17 Dec 2013 00:55:56 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 31599 invoked by uid 89); 17 Dec 2013 00:55:55 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 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-ee0-f54.google.com Received: from mail-ee0-f54.google.com (HELO mail-ee0-f54.google.com) (74.125.83.54) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 17 Dec 2013 00:55:55 +0000 Received: by mail-ee0-f54.google.com with SMTP id e51so2177771eek.13 for ; Mon, 16 Dec 2013 16:55:52 -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=UP2GQ3dUtI82TMD4iWGG/FWc6PrLuZduecOM8uRh7p8=; b=X1dYHBjRYny5kZhj+TJLK9X26PovjGBjgYTvcphn96m2KLmXg92bkkzsYl9b/DIx6C PTfF2hJkT6o87P+1nw0aMiq/CX59+tlTyEYzvfML+BIx+4uftw9WlRQSrbYIwuPrMqH4 9G0rmCQURcdTMFFFXMejecIx5xA3RWz8pA+sbodfy4L+aojZ5lFzw7QoCnqjCg4FKcqf dPi7gU8Ni/vp0kWY7ANVLeDY7/15nUm4R5xRYYZvq1NegnioWSh57rcIxz85zcEdQH9M CT6/ajDHTMcPs29wWeMHYoE1KPkUYkzDoHnuGz+1AY9ASgbyI5eFuZR8SXqM6BBUSUAZ mxIw== X-Gm-Message-State: ALoCoQlOcpD5JwulBDrnjR8v9FR+KjaUw1QsLDUWQGfyAFa2Wiu8dB+O8ZTgi1XSilIwlpmIwDtopACUEb419wtjFdkRle14dL1UKryg4kH5USNN9FUi1GJER2z3MOP3mlMRvh9OBUgoEljVKkZgs8Zm+E76Z7p+TjfEuoFUVmaFLG9JHb6I/7ON4XFW44mHoi8vnaEt+Uj5 MIME-Version: 1.0 X-Received: by 10.15.61.134 with SMTP id i6mr19656183eex.48.1387241751951; Mon, 16 Dec 2013 16:55:51 -0800 (PST) Received: by 10.14.151.72 with HTTP; Mon, 16 Dec 2013 16:55:51 -0800 (PST) In-Reply-To: <87bo0gpg4f.fsf@fleche.redhat.com> References: <87bo0gpg4f.fsf@fleche.redhat.com> Date: Tue, 17 Dec 2013 00:55:00 -0000 Message-ID: Subject: Re: Invoking methods on gdb.Value objects and other ideas From: Siva Chandra To: Tom Tromey Cc: gdb@sourceware.org Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2013-12/txt/msg00039.txt.bz2 Siva> 5. Method invocation via [] operator - One should be able to invoke Siva> methods on a gdb.Value object like this: Siva> value_obj[method](arg1, arg2, ...) Siva> METHOD can be a gdb.TypeMethod, or a gdb.ValueMethod object. Siva> 6. Unresolved methods - Value and type objects should have Python Siva> method "get_method". Siva> m = value_obj.get_method(method) Siva> METHOD is a string value name of the method. M is a yet unresolved Siva> method (due to overloading) but can used to invoke the method like in Siva> 4 and 5 above. The method is resolved based on the args. Tom> It seems to me that #5 and #6 are just two different ways to write the Tom> same thing. More or less. Yes, more or less :-) But, note that the method "get_method" takes a string arg, whereas the operand to '[]' is _not_ a string. It is a gdb.TypeMethod or gdb.ValueMethod object. Tom> Note that a danger of using strings and overloading [] is that in Java Tom> (and maybe other languages, I don't know) a method and an ordinary field Tom> can have the same name. I think this would make the syntax ambiguous Tom> there -- is value['name'] a reference to a field or to a bound method? As I mentioned above, we do not use a string operand with '[]' to get methods. Tom> Perhaps having just get_method is better for this reason. But, do you think we should not have support for '[]' as described above? Tom> The above seem to be found methods, but it seems that to be complete Tom> you'd also want a way to create a C++ pointer-to-member. I guess this Tom> is more cleanly done via the Type API, or perhaps a method on your Tom> proposed TypeMethod object. I think you mean "bound" methods. I refrained from using that term as they could be yet unresolved, and they are not gdb.TypeMethod or gdb.ValueMethod objects. But, I do not have any real reason to not call them bound methods. About C++ pointer-to-member values, I think they are in a way methods already, and hence could just be invoked by '(...)' method invocation? Siva> 8. Debug method caching in the underlying "struct type" [3] - If a Siva> particular debug matches for a type, then cache it in the type. Future Siva> similar invocations need go through all debug methods for a match Siva> (unless of course new debug methods are registered in the meanwhile). Tom> I wasn't sure about this but I think the idea must be that the internals Tom> cache the result of some other lookup; so that having multiple structs Tom> representing the same type can't cause a problem. So, it is a Tom> performance optimization rather than an integral part of the lookup Tom> machinery. Siva> 9. Caching debug methods matches to disk - This is for a use case Siva> wherein a GDB user does not write his own debug methods but ends up Siva> implicitly using debug methods defined for a library not written by Siva> him. For such cases, one could cache the debug method matches to disk Siva> so that future GDB sessions save on debug method search. Tom> I don't understand this one. I think you should ignore #7, #8 and #9. My mistake to have mixed them up here with the discussion on method invocation.