From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4155 invoked by alias); 10 Oct 2005 23:53:45 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 4134 invoked by uid 22791); 10 Oct 2005 23:53:43 -0000 Received: from tully.cs.berkeley.edu (HELO tully.CS.Berkeley.EDU) (128.32.153.227) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Mon, 10 Oct 2005 23:53:43 +0000 Received: from tully.CS.Berkeley.EDU (localhost [127.0.0.1]) by tully.CS.Berkeley.EDU (8.12.7/8.12.7/3.141592645) with ESMTP id j9ANrO9S014316; Mon, 10 Oct 2005 16:53:24 -0700 (PDT) Received: from tully.CS.Berkeley.EDU (hilfingr@localhost) by tully.CS.Berkeley.EDU (8.12.7/8.12.7/Submit) with ESMTP id j9ANrKYp014313; Mon, 10 Oct 2005 16:53:24 -0700 (PDT) Message-Id: <200510102353.j9ANrKYp014313@tully.CS.Berkeley.EDU> To: David Lecomber cc: gdb , hilfingr@otisco.mckusick.com Subject: Re: Laziness In-Reply-To: Message from Daniel Jacobowitz of "Mon, 10 Oct 2005 17:27:31 EDT." <20051010212731.GA6596@nevyn.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <14309.1128988399.1@tully.CS.Berkeley.EDU> Date: Mon, 10 Oct 2005 23:53:00 -0000 From: Paul Hilfinger X-SW-Source: 2005-10/txt/msg00069.txt.bz2 > On Mon, Oct 10, 2005 at 10:42:18PM +0100, David Lecomber wrote: > > That value_contents_all and massive read is happening a good few seconds > > before we start doing the repeated elements comparison in > > val_print_array_elements.. > > Then that's a different issue: gdb must just not support reading array > elements lazily... that will take more work to fix. That's right. For Ada, it's been a recurring problem, possibly because Ada allows one to explicitly describe arrays whose size is data-dependent. So far we (AdaCore) has kludged around the resulting performance problems in GDB in piecemeal fashion. Perhaps this would be a good time to consider more elegant and general approaches, if they will find an audience outside Ada. Of course, one can do this "by hand" (or by hand-crafted user-defined command) with explicit pointer hacking, but perhaps we might seek a more user-friendly solution. An obvious approach is to re-do the struct value API to further lazify (sedate?) it. Currently, values are fetched when needed, but a. GDB pre-allocates space for the whole eventual value, however huge, and b. When the value is delazified, GDB fetches the entire object. With some enhancements to the struct value API and better enforcement of its proper use, we could introduce a scheme that a. Lazily allocated memory, as well as lazily fetching. b. Allowed for lazily slicing out subcomponents of a composite value without GDB memory allocation for the target data. On a separate but related note, I also envision a kind of "struct value iterator" that allows one to sequence through a composite object with a single struct value object, avoiding even the creation of new struct values. Such a mechanism could replace what the print routines use now, which is basically a method of fetching target memory given an address and type that is completely independent of the the struct value mechanism. There would be no functional improvement, but I imagine we could clean things up a bit. If any of this elicits interest, we might be persuaded to do the work. Paul Hilfinger AdaCore consultant