From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5444 invoked by alias); 29 Apr 2008 14:19:30 -0000 Received: (qmail 5424 invoked by uid 22791); 29 Apr 2008 14:19:27 -0000 X-Spam-Check-By: sourceware.org Received: from imr2.ericy.com (HELO imr2.ericy.com) (198.24.6.3) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 29 Apr 2008 14:19:06 +0000 Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id m3TEIqpl013129; Tue, 29 Apr 2008 09:18:54 -0500 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Apr 2008 09:18:32 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [PATCH:MI] Return a subset of a variable object's children Date: Tue, 29 Apr 2008 15:58:00 -0000 Message-ID: <6D19CA8D71C89C43A057926FE0D4ADAA042910A5@ecamlmw720.eamcs.ericsson.se> In-Reply-To: <18452.24568.655617.907458@kahikatea.snap.net.nz> From: "Marc Khouzam" To: "Nick Roberts" , 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/msg00655.txt.bz2 > From: gdb-patches-owner@sourceware.org on behalf of Nick Roberts > Sent: Sunday, April 27, 2008 7:14 AM >=20 > This patch allows -var-list-children to create just some of a variable ob= ject's > children. Following a discussion last year with Mark Khouzam, this is us= eful > 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 allo= ws a Cool! To be fully transparent though, DSF does not yet have a way to deal with di= fferent behavior of different GDBs, so we won't be using such improvements right aw= ay. We stick to common behaviors, until we can handle differences cleanly. But such improvements may prove useful in the future. > step size (stride) other than one. I'm not sure what the stride would be used for. Maybe something like print= ing all even indexes of an array for example? In any case, it is a pretty simple addition, and no one is forced to use it, so I'm only asking to understand better. > 2008-04-27 Nick Roberts >=20 > * mi/mi-cmd-var.c (mi_cmd_var_list_children): Add options to select > a subset of children. >=20 > * varobj.h (varobj_list_children): Declare new parameters. >=20 > * varobj.c (struct varobj): New member current_children. > (varobj_list_children): Create any new varobjs for children > specified by mi_cmd_var_list_children. > (create_child): Add parameter real_index. Use it. >=20 I have a concern about the ordering of children. I think not having a constant ordering for the children could prove a probl= em. For example, I think the algorithm proposed will fail if a child varObj is deleted by the user. I believe deleting a varObj inserts NULL in its current position, however, the algo always inserts at the end, so it will miss the available deleted entry. Also, the double loop may prove to be slow for large number of children. I was thinking that we could keep order of children as they are defined (current behaviour) but not fill them all, until requested. We could create the full Vector of children as is done now by while (VEC_length (varobj_p, var->children) < var->num_children) VEC_safe_push (varobj_p, var->children, NULL); but only actually create the children that have been requested by the user. I'm not sure how much efficiency there is by allocating the memory before h= and? Also, is there no way to grow the vector by more than a single point at a t= ime? We can even improve on that by doing the following: instead of allocating the vector for all children, we can allocate the vect= or for the children up to start+number*stride. I believe this will give a constant ordering (same as current) and avoid the costly double loop, since we can simply check for NULL to know if a child is there or not. And the delete will work as is. You can also probably use the vector size instead of the new current_childr= en. >=20 > *** mi-cmd-var.c 20 Apr 2008 10:20:39 +1200 1.50 > --- mi-cmd-var.c 27 Apr 2008 21:34:58 +1200 > *************** mi_cmd_var_list_children (char *command, [...] > ! if (argc =3D=3D 1 || argc =3D=3D 2) > ! { > ! /* Get varobj handle, if a valid var obj name was specified */ > ! if (argc =3D=3D 1) > ! var =3D varobj_get_handle (argv[0]); > ! else > ! var =3D varobj_get_handle (argv[1]); > ! if (var =3D=3D NULL) > ! error (_("Variable object not found")); > !=20 > ! if (argc =3D=3D 2) > ! print_values =3D mi_parse_values_option (argv[0]); > ! else > ! print_values =3D PRINT_NO_VALUES; > !=20 > ! start =3D 0; > ! number =3D varobj_get_num_children (var); > ! } > else > ! { > ! int optind =3D 0; > ! char *optarg; > ! while (1) > ! { > ! int opt =3D mi_getopt ("mi_cmd_var_list_children", > ! argc, argv, opts, &optind, &optarg); It would be nice to use the string -var-list-children instead of mi_cmd_var_list_children, since it may be used to print an error to the use= r. > ! if (optind >=3D argc) > ! error (_("Missing VARNAME")); It would be nice to have the full Usage printed here. =20=20 > ! if (optind < argc - 1) > ! error (_("Garbage at end of command")); > !=20 > ! var =3D varobj_get_handle (argv[optind]); =20 Here, you need the var =3D=3D NULL check again: =20=20=20=20 if (var =3D=3D NULL) error (_("Variable object not found")); Or you can extract it from the if above and put it outside the if/else Thanks for getting this started. Marc