From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31142 invoked by alias); 14 Nov 2003 00:19:46 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 31135 invoked from network); 14 Nov 2003 00:19:45 -0000 Received: from unknown (HELO mail-out4.apple.com) (17.254.13.23) by sources.redhat.com with SMTP; 14 Nov 2003 00:19:45 -0000 Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out4.apple.com (8.12.10/8.12.9) with ESMTP id hAE0Jinc026099 for ; Thu, 13 Nov 2003 16:19:44 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 13 Nov 2003 16:19:11 -0800 Received: from [17.201.22.21] (moleja.apple.com [17.201.22.21]) by scv1.apple.com (8.12.9/8.12.9) with ESMTP id hAE0JDww026088; Thu, 13 Nov 2003 16:19:13 -0800 (PST) In-Reply-To: <16298.50534.258926.575817@nick.uklinux.net> References: <16298.50534.258926.575817@nick.uklinux.net> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <291E7712-1638-11D8-AA48-000393D457E2@apple.com> Content-Transfer-Encoding: 7bit Cc: gdb@sources.redhat.com From: Jason Molenda Subject: Re: MI command -stack-list-locals Date: Fri, 14 Nov 2003 00:19:00 -0000 To: Nick Roberts X-SW-Source: 2003-11/txt/msg00096.txt.bz2 Hi Nick, sorry for the late reply. On Nov 6, 2003, at 2:04 PM, Nick Roberts wrote: > This can be a nuisance > with large arrays or structures and I would like to extend > -stack-list-locals > to do the following: > > 1) Display the name and value for simple data types. > 2) Display the name and type for complex data types. > > e.g with the local variables: > > int i, m[10]; > struct { > int j; > int k; > } values; > > the output for "-stack-list-locals 2", say, would be: > > ^done,locals=[{name="i",value="5"}, > {name="m",type="int [10]"} > {name="values",type="struct {...}"}] We've been handling many of the same issues here at Apple for the past few years. Jim's the real expert in regard to our varobj modifications, but here's a quick example that might be helpful for your problem. We've added a "2" version of -stack-list-locals which prints out a lot more information, as well as automatically creates varobj's for all of the local variables. On the above example, we output -stack-list-locals 2 ^done,locals=[ varobj={exp="i",value="5",name="var1",numchild="0",type="int",typecode=" INT",dynamic_type="",in_scope="true",block_start_addr="0x00001dd0",block _end_addr="0x00001e04"}, varobj={exp="m",value="[-1]",name="var2",numchild="10",type="int [10]",typecode="ARRAY",dynamic_type="",in_scope="true",block_start_addr= "0x00001dd0",block_end_addr="0x00001e04"}, varobj={exp="values",value="{...}",name="var3",numchild="2",type="struct {...}",typecode="STRUCT",dynamic_type="",in_scope="true",block_start_add r="0x00001dd0",block_end_addr="0x00001e04"} ],time={wallclock="0.00179",user="0.01000",system="0.00000",start="10687 68005.990265",end="1068768005.992059"} I inserted some newlines to make it more readable; of course it's all on one line in the real output. The type of the variable is in the TYPE field; the TYPECODE field is a general description for the IDE -- it is the string representation of the TYPE_CODE of the varobj (e.g. PTR, ARRAY, STRUCT, ENUM, INT, FLT, etc.) which gives the UI an easy way to tell how it should be represented to the user. IN_SCOPE works correctly with our gdb. DYNAMIC_TYPE is to represent when a varobj is pointer to a C++ class that may point to classes higher up the inheritance tree so the UI can keep its display up to date as the type changes. Oh, and the TIME thing at the end is just a little performance monitor deal we use internally when we're hunting for slow-downs between the UI and gdb; that doesn't have anything to do with the varobj's. Jason