From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7013 invoked by alias); 30 Apr 2008 05:59:17 -0000 Received: (qmail 6995 invoked by uid 22791); 30 Apr 2008 05:59:16 -0000 X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 30 Apr 2008 05:58:57 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Jr5LB-0004v4-6A for gdb-patches@sources.redhat.com; Wed, 30 Apr 2008 05:58:53 +0000 Received: from 78.158.192.230 ([78.158.192.230]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 30 Apr 2008 05:58:53 +0000 Received: from vladimir by 78.158.192.230 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 30 Apr 2008 05:58:53 +0000 To: gdb-patches@sources.redhat.com From: Vladimir Prus Subject: Re: [PATCH:MI] Return a subset of a variable object's children Date: Wed, 30 Apr 2008 08:59:00 -0000 Message-ID: References: <18452.24568.655617.907458@kahikatea.snap.net.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit User-Agent: KNode/0.10.5 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-04/txt/msg00683.txt.bz2 Nick Roberts wrote: > > This patch allows -var-list-children to create just some of a variable object's > children. Following a discussion last year with Mark Khouzam, this is useful > for displaying large arrays (and structures) where it would take too long to > create all the children: it is only really necessary to create those that are > visible on the screen and update as further become visible. It also allows a > step size (stride) other than one. > > ISTR that it was said a long time ago that mi_getopt won't take long options > but that doesn't seem to be the case. The difficulty is that > -var-list-children takes 0, 1 and 2 as options so I've had to separate the > logic to keep it backward compatible. > > Use of these new options means that the elements might not be printed in order > but it is always preserved if only the old options are used. Thanks for working on this. Some concerns: 1. Can you please post MI patches in the unified diff format. I have troubles groking context diff, so actual review of the code may be delayed. 2. Do we need the stride? One this feature is in, we no longer can remove it, and if there's no pressing need we should not add it. 3. I'm not very comfortable with creating the children, and reporting them, out-of-order. I think if I'm asking for childrem from 10 to 20, I should get exactly the children I've asked for. If I can potentially also get children from 20 to 30, then followed by children from 10 to 20, it means the frontend will have to do some smarts to find the new children and put them in the right place. GDB surely know which children it created, so it can report just them. Thanks, Volodya