Re: Laziness

[Paul Hilfinger <hilfingr@EECS.Berkeley.EDU>]

> 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