From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11162 invoked by alias); 4 Oct 2011 15:51:29 -0000 Received: (qmail 11151 invoked by uid 22791); 4 Oct 2011 15:51:28 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from qmta03.westchester.pa.mail.comcast.net (HELO qmta03.westchester.pa.mail.comcast.net) (76.96.62.32) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 04 Oct 2011 15:51:12 +0000 Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta03.westchester.pa.mail.comcast.net with comcast id gbLW1h00K1ZXKqc53frCTP; Tue, 04 Oct 2011 15:51:12 +0000 Received: from [10.127.238.91] ([65.206.2.68]) by omta21.westchester.pa.mail.comcast.net with comcast id gfr11h01P1U2a2h3hfr4y6; Tue, 04 Oct 2011 15:51:10 +0000 Subject: Re: Python: fetch value when building gdb.Value object Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Koning In-Reply-To: Date: Tue, 04 Oct 2011 15:51:00 -0000 Cc: gdb-patches@sourceware.org Content-Transfer-Encoding: quoted-printable Message-Id: <21467A42-84A3-4DFD-83A9-28FFFB0A5C7F@comcast.net> References: <36B29E9D-F2B3-446F-AF8A-97254A3AAEE2@comcast.net> To: Tom Tromey 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 X-SW-Source: 2011-10/txt/msg00089.txt.bz2 On Oct 4, 2011, at 11:44 AM, Tom Tromey wrote: >>>>>> "Paul" =3D=3D Paul Koning writes: >=20 > Paul> GDB sometimes lazily evaluates operations on values, and > Paul> py-value.c wasn't taking that into account. The result was that > Paul> assigning a Value object to a Python variable could assign a lazy > Paul> value, so that any errors in accessing the data would occur at a > Paul> later time, and sometimes would not be handled right. (For > Paul> example, the "nonzero" operation would fail without a Python > Paul> traceback.) The attached patch cures this by fetching any lazy > Paul> values when the gdb.Value object is built, and adds a test in the > Paul> testcases to verify this. >=20 > Paul> Ok to submit? >=20 > I am not convinced that this is the right approach. >=20 > I think it would probably be better to expose the laziness to the Python > programmer -- via a new attribute and a new method to un-lazy the > object. >=20 > The reason is that eager fetching can be very expensive. E.g., you may > construct an intermediate value that is a very large array, but intend > only to reference a few elements. This can be done efficiently by gdb, > but eager fetching will defeat that. I modeled what I did after the way the existing GDB code handles convenienc= e variables. It seemed logical that set $foo =3D *ptr and python foo=3Dgdb.eval ("*ptr") should behave the same. With the patch, they do, because in both case the = lazy evaluation is done.=20 paul