From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9909 invoked by alias); 9 Jan 2008 19:05:42 -0000 Received: (qmail 9887 invoked by uid 22791); 9 Jan 2008 19:05:37 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 09 Jan 2008 19:05:12 +0000 Received: (qmail 27283 invoked from network); 9 Jan 2008 19:05:10 -0000 Received: from unknown (HELO localhost) (jimb@127.0.0.2) by mail.codesourcery.com with ESMTPA; 9 Jan 2008 19:05:10 -0000 To: "Pierre Muller" Cc: "'Joel Brobecker'" , Subject: Re: [RFA] Add handling of null Ada arrays References: <20080109063342.GE20580@adacore.com> <000401c852a1$0bdb1aa0$23914fe0$@u-strasbg.fr> From: Jim Blandy Date: Wed, 09 Jan 2008 19:05:00 -0000 In-Reply-To: <000401c852a1$0bdb1aa0$23914fe0$@u-strasbg.fr> (Pierre Muller's message of "Wed, 9 Jan 2008 10:21:42 +0100") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IsSubscribed: yes 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: 2008-01/txt/msg00202.txt.bz2 "Pierre Muller" writes: > At least in pascal language it is quite > common to use things like > type > BigArray = Array [1..0xffffffff] of integer; > if you want to be sure that you will never get into > troubles due to range checking... > > Of course you cannot allocate a pointer to such a type > directly, and it would eat up a lot of memory space. > But this kind of types always gave problems > inside gdb, because when you wanted to look at > the value gdb would try to copy the whole array... > even if cases where it would only display the first elements, > which is kind of silly, no? Interesting. I see print_command_1 calls record_latest_value, which says: /* We don't want this value to have anything to do with the inferior anymore. In particular, "set $1 = 50" should not affect the variable from which the value was taken, and fast watchpoints should be able to assume that a value on the value history never changes. */ if (value_lazy (val)) value_fetch_lazy (val); If GDB were to support those types of values nicely, how would GDB save such values in the value history without reading the whole thing? Even if that could be addressed, the common val_print routine expects to have the whole object in memory. That's a shame.