From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13197 invoked by alias); 16 Dec 2013 22:48:05 -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 13174 invoked by uid 89); 16 Dec 2013 22:48:05 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 16 Dec 2013 22:48:04 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rBGMm26p016682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 16 Dec 2013 17:48:02 -0500 Received: from barimba (ovpn-113-93.phx2.redhat.com [10.3.113.93]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id rBGMm057005290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 16 Dec 2013 17:48:01 -0500 From: Tom Tromey To: Siva Chandra Cc: gdb@sourceware.org Subject: Re: Invoking methods on gdb.Value objects and other ideas References: Date: Mon, 16 Dec 2013 22:48:00 -0000 In-Reply-To: (Siva Chandra's message of "Fri, 13 Dec 2013 09:46:16 -0800") Message-ID: <87bo0gpg4f.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2013-12/txt/msg00037.txt.bz2 >>>>> "Siva" == Siva Chandra writes: Siva> I am sharing some of my ideas on how we could facilitate invoking Siva> source language methods (and debug methods) on gdb.Value objects. Thanks. Siva> 1. Bring in a class hierarchy of gdb types. That is, have a base class Siva> gdb.Type from which other classes gdb.TypeStruct, gdb.TypeMethod etc Siva> are derived. Sounds good. We probably should have done it from the start. Siva> 2. Do the same with gdb.Value class. That is, have a base class Siva> gdb.Value from which other classes gdb.ValueStruct, gdb.ValueMethod Siva> etc. are derived. I am not very sure if this is really required, but I Siva> can think of atleast one reason why this can be cleaner. Likewise. 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. It seems to me that #5 and #6 are just two different ways to write the same thing. More or less. Note that a danger of using strings and overloading [] is that in Java (and maybe other languages, I don't know) a method and an ordinary field can have the same name. I think this would make the syntax ambiguous there -- is value['name'] a reference to a field or to a bound method? Perhaps having just get_method is better for this reason. The above seem to be found methods, but it seems that to be complete you'd also want a way to create a C++ pointer-to-member. I guess this is more cleanly done via the Type API, or perhaps a method on your proposed TypeMethod object. 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). I wasn't sure about this but I think the idea must be that the internals cache the result of some other lookup; so that having multiple structs representing the same type can't cause a problem. So, it is a performance optimization rather than an integral part of the lookup 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. I don't understand this one. Tom