From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12611 invoked by alias); 14 Sep 2009 20:21:19 -0000 Received: (qmail 12601 invoked by uid 22791); 14 Sep 2009 20:21:19 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_13,J_CHICKENPOX_17,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 14 Sep 2009 20:21:14 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n8EKLB2t002169; Mon, 14 Sep 2009 16:21:11 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id n8EKLAf4029947; Mon, 14 Sep 2009 16:21:10 -0400 Received: from opsy.redhat.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n8EKL9qu005049; Mon, 14 Sep 2009 16:21:09 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id D8647378175; Mon, 14 Sep 2009 14:21:08 -0600 (MDT) From: Tom Tromey To: nickrob@snap.net.nz (Nick Roberts) Cc: gdb-patches@sourceware.org Subject: Re: Patch: implement new dynamic varobj spec References: <19116.23500.574462.227048@totara.tehura.co.nz> Reply-To: Tom Tromey Date: Mon, 14 Sep 2009 20:21:00 -0000 In-Reply-To: (Tom Tromey's message of "Mon, 14 Sep 2009 14:12:11 -0600") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: 2009-09/txt/msg00451.txt.bz2 >>>>> "Tom" == Tom Tromey writes: Tom> Oh, odd. But not a bug, really, as the order is not specified. Nick> It might not be a bug but it's desirable to list them in order as Nick> that makes it easier to insert them into the existing list. Tom> Ok, I will look into this. Could you try the appended patch? If it works for you I will roll it into the main patch. Tom diff --git a/gdb/varobj.c b/gdb/varobj.c index e7fb589..7235635 100644 --- a/gdb/varobj.c +++ b/gdb/varobj.c @@ -1759,7 +1759,6 @@ VEC(varobj_update_result) *varobj_update (struct varobj **varp, int explicit) { VEC (varobj_p) *changed = 0, *new = 0, *unchanged = 0; int i, children_changed; - varobj_p tmp; if (v->frozen) continue; @@ -1799,15 +1798,21 @@ VEC(varobj_update_result) *varobj_update (struct varobj **varp, int explicit) r.children_changed = 1; r.new = new; } - for (i = 0; VEC_iterate (varobj_p, changed, i, tmp); ++i) + /* Push in reverse order so that the first child is + popped from the work stack first, and so will be + added to result first. This does not affect + correctness, just "nicer". */ + for (i = VEC_length (varobj_p, changed) - 1; i >= 0; --i) { + varobj_p tmp = VEC_index (varobj_p, changed, i); varobj_update_result r = {tmp}; r.changed = 1; r.value_installed = 1; VEC_safe_push (varobj_update_result, stack, &r); } - for (i = 0; VEC_iterate (varobj_p, unchanged, i, tmp); ++i) + for (i = VEC_length (varobj_p, unchanged) - 1; i >= 0; --i) { + varobj_p tmp = VEC_index (varobj_p, unchanged, i); if (!tmp->frozen) { varobj_update_result r = {tmp};