From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13041 invoked by alias); 18 Dec 2013 16:37:37 -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 13027 invoked by uid 89); 18 Dec 2013 16:37:37 -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_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-we0-f171.google.com Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com) (74.125.82.171) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 18 Dec 2013 16:37:36 +0000 Received: by mail-we0-f171.google.com with SMTP id q58so7712327wes.2 for ; Wed, 18 Dec 2013 08:37:32 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.24.99 with SMTP id t3mr4753078wif.1.1387384652710; Wed, 18 Dec 2013 08:37:32 -0800 (PST) Received: by 10.194.123.4 with HTTP; Wed, 18 Dec 2013 08:37:32 -0800 (PST) In-Reply-To: References: <871u1j2ldi.fsf@fleche.redhat.com> Date: Wed, 18 Dec 2013 16:37:00 -0000 Message-ID: Subject: Re: [RFC/Patch] Call overloaded operators to perform valid Python operations on struct/class values. 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-12/txt/msg00709.txt.bz2 On Mon, Dec 16, 2013 at 2:24 PM, Siva Chandra wrote: > On Sun, Dec 15, 2013 at 11:48 PM, Doug Evans wrote: >> For myself, I'm just going slow on this one. E.g., is there another >> way to provide this? >> E.g., some kind of facility that uses gdb's language parsers but let's >> one pass in gdb.Value objects from Python? >> It sounds doable, but I haven't thought about it very hard (it might >> not even make sense, or it may require more effort). >> Its drawback to the current proposal is that it would be a bit more >> verbose, but it has to potential of handling a lot more cases. > > I am not sure I fully understand this alternative. It could be done in various ways I think. One way would be language parsers and the evaluator have some way of recognizing a value as coming from an extension language and fetch the underlying gdb value accordingly. Kinda like the gdb.parse_and_eval method in Python, but with the ability to pass Python values to it. Not that this could work, but for illustration's sake: smart_ptr = gdb.parse_and_eval ("my_smart_ptr"); dereferenced_smart_ptr = gdb.parse_and_eval("*%V" % smart_ptr) I can think of a quick hack that was just a wrapper on parse_and_eval that used some convenience variables to temporarily hold the values that came from Python (using some syntax that worked, the above is just for illustration's sake). > My patch adds the > ability to use valid Python operators on gdb.Value objects in Python > code. Operators which have different semantics in Python (like '[]', > ',' etc.), and operators which do not exist in Python (like '->') > cannot be facilitated. But, my patch adds the ability to use all > other operators which are valid (as far as my understanding today > stands at) in Python.