From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12400 invoked by alias); 22 Aug 2012 17:29:09 -0000 Received: (qmail 12381 invoked by uid 22791); 22 Aug 2012 17:29:07 -0000 X-SWARE-Spam-Status: No, hits=-3.6 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,KHOP_THREADED,SARE_MILLIONSOF X-Spam-Check-By: sourceware.org Received: from localhost (HELO sourceware.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 22 Aug 2012 17:28:55 +0000 From: "tromey at redhat dot com" To: gdb-prs@sourceware.org Subject: [Bug mi/13419] Unable to pretty-print map of lists Date: Wed, 22 Aug 2012 17:29:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: mi X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: tromey at redhat dot com X-Bugzilla-Status: WAITING X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Status CC Version Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gdb-prs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-prs-owner@sourceware.org X-SW-Source: 2012-q3/txt/msg00267.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=13419 Tom Tromey changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |WAITING CC| |tromey at redhat dot com Version|unknown |HEAD --- Comment #1 from Tom Tromey 2012-08-22 17:28:39 UTC --- It all seems pretty reasonable to me, but I'm not totally sure what problem you are seeing. (gdb) p m $2 = std::map with 2 elements = { ["one"] = std::list = { [0] = "a", [1] = "b", [2] = "c" }, ["two"] = std::list = { [0] = "1", [1] = "2", [2] = "3" } } That's the baseline. Now for MI: (gdb) -enable-pretty-printing ^done (gdb) -var-create - * m ^done,name="var1",numchild="0",value="{...}",type="map_t",thread-id="1",displayhint="map",dynamic="1",has_more="1" (gdb) -var-list-children --all-values var1 ^done,numchild="4",displayhint="map",children=[child={name="var1.[0]",exp="[0]",numchild="0",value=" \"one\"",type="const std::basic_string, std::allocator >",thread-id="1",displayhint="string",dynamic="1"},child={name="var1.[1]",exp="[1]",numchild="0",value="{...}",type="std::list, std::allocator >, std::allocator, std::allocator > > >",thread-id="1",dynamic="1"},child={name="var1.[2]",exp="[2]",numchild="0",value=" \"two\"",type="const std::basic_string, std::allocator >",thread-id="1",displayhint="string",dynamic="1"},child={name="var1.[3]",exp="[3]",numchild="0",value="{...}",type="std::list, std::allocator >, std::allocator, std::allocator > > >",thread-id="1",dynamic="1"}],has_more="0" A few things to note here. First, dynamic varobjs must be handled differently from ordinary ones. This is why the MI client has to request them. It is usually wrong to request all the children, you should request just a range of them. Otherwise you can be overwhelmed with data, like if the user tries to show a vector with millions of elements. In this output, the display hint tells the MI client some useful info. In particular it says that var1.[0] is a key, var1.[1] is an element, etc. I'm not sure why this doesn't list the children of var1.[1] -- I don't know if that is a dynamic/static varobj difference, or just the norm, or even if it is intended. But in any case it is easy to ask for the children of var1.[1]: -var-list-children --all-values var1.[1] ^done,numchild="3",children=[child={name="var1.[1].[0]",exp="[0]",numchild="0",value=" \"a\"",type="std::basic_string, std::allocator >",thread-id="1",displayhint="string",dynamic="1"},child={name="var1.[1].[1]",exp="[1]",numchild="0",value=" \"b\"",type="std::basic_string, std::allocator >",thread-id="1",displayhint="string",dynamic="1"},child={name="var1.[1].[2]",exp="[2]",numchild="0",value=" \"c\"",type="std::basic_string, std::allocator >",thread-id="1",displayhint="string",dynamic="1"}],has_more="0" The "{...}" thing is unfortunate. It was requested by the MI maintainer when dynamic varobjs were written. In most cases I think it doesn't matter much; but perhaps we can change it someday. Could you maybe say what in the above is causing problems? -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.