From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20688 invoked by alias); 3 Jan 2015 21:27:52 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 20674 invoked by uid 89); 3 Jan 2015 21:27:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mail-ob0-f181.google.com Received: from mail-ob0-f181.google.com (HELO mail-ob0-f181.google.com) (209.85.214.181) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Sat, 03 Jan 2015 21:27:49 +0000 Received: by mail-ob0-f181.google.com with SMTP id gq1so56600706obb.12 for ; Sat, 03 Jan 2015 13:27:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=1+giw8jOeU/upCQFH38AKEL4qA6GAMUfNRZdyLN6Fxs=; b=IFZtFPmFernnWum4+hWe6OhRvGumWGvMLi9wo1dv8gFQBv0y9LVTOk1QMyGbv2urZ5 L5enXBsLEF5usOVa98T+7wOAQqPXNcCI5sUW24AU8Lkt9DlS+ql4HAmu4HYEpCtHdeEX FU6DXksXPmSQPmGkEhswpigO2H4KVJRMO90+DrvQviYZ+vhnJA5dc2AsyAMuwPDPWOnM 0jeIgInyCON6wO++PAXMKueuFLXVqN026aGMMDLFnomSZMn7RP1ZH74dENzwATlPkR86 Hkbcq/W02Z0Z8QonkioyKMtiP+yEMQLOr6VE/XHtBmFBpyWGsIFqfBItYTMjhS+S98aY XPcg== X-Gm-Message-State: ALoCoQm9JOAABQRPMORyw+a6GK205WHa6Vd0FZhJXOAildv5AnwPrh3AHRMMs+QFHYknmRY4uiYB MIME-Version: 1.0 X-Received: by 10.60.173.211 with SMTP id bm19mr48546420oec.66.1420320466941; Sat, 03 Jan 2015 13:27:46 -0800 (PST) Received: by 10.182.222.98 with HTTP; Sat, 3 Jan 2015 13:27:46 -0800 (PST) In-Reply-To: References: Date: Sat, 03 Jan 2015 21:27:00 -0000 Message-ID: Subject: Re: Getting the "description" of a variable From: Doug Evans To: Siva Chandra Cc: gdb Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-01/txt/msg00011.txt.bz2 On Fri, Jan 2, 2015 at 2:26 PM, Doug Evans wrote: > On Thu, Dec 18, 2014 at 5:00 PM, Siva Chandra wrote: >> Hello, >> >> As with most of my questions, I am really not sure if the subject line >> is good/apt for my question. The question is, "how can I get the >> description of a variable from the GDB command line?" >> >> By description, I mean this: >> 1. File and line it is declared at. >> 2. Its type and scope. >> >> I think GDB already has ways to get this information using multiple commands. >> >> My use case can be illustrated with an example. Consider the following >> C++ snippet. >> >> class Counter >> { >> public: >> int inc(); >> >> int count; >> }; >> >> int >> Counter::inc () >> { >> count++; >> return count; >> } >> >> class A >> { >> public: >> int inc(); >> >> static Counter counter; >> }; >> >> Counter A::counter; >> >> int >> A::inc () >> { >> counter.inc(); // Break here >> } >> >> int >> main () >> { >> A a; >> >> a.inc(); >> >> return 0; >> } >> >> Lets say I am new to this code and single stepping through it and >> currently stopped at the line marked with "Break here". I now want to >> know what this variable "counter" is. I print its value, and print its >> type. If I do "info variables counter", one of the results is >> "A::counter" and I realize that it is a static member of class A. >> Next, I can use gdb.lookup_symbol('A::counter') to get to the filename >> and line number where it is declared. There are a few problems I face >> when I use this kind of workflow: >> >> 1. Too many steps to get to what I want. If I am interrupted, I loose >> track of where I am and will have to start from the beginning all >> over. >> 2. gdb.lookup_symbol('counter') returns (None, True). I have to use >> gdb.lookup_symbol('A::counter'). >> 3. The filename and line number I get via gdb.lookup_symbol is mostly >> likely the location where the static member is declared out of the >> class in a *.cc file. This is not good enough because the comments >> describing this member are typically found in a *.h file where the >> class is defined. So, I will need another step via >> gdb.lookup_symbol('A') to get to the line and file where the class A >> is defined. >> >> Is there a shorter workflow to get the same information already existing in GDB? >> >> If not: >> >> 1. Is it OK to add more info to 'struct symbol' to store all the files >> and lines where a "symbol" is declared. If not 'struct symbol', is >> there a better place where such info can be added? >> 2. If #1 is OK, then, can we add a command 'describe' using GDB Python >> which prints the info I am looking for? > > Hi. > Just a couple of initial thoughts. > > Users shouldn't have to use python for anything you're trying to do here, > so if that's currently a better way to accomplish something (or even > the only way) then that is something we need to fix. > [This is different than implementing a command in python, > here I'm talking about what the user has to type.] > > Re: #1: Adding anything to struct symbol is "a big deal". > > [I've been thinking IWBN if we could record in symbols (and types) > links back to the raw debug info, and then have an API for accessing > infrequently accessed parts that reparse the debug info every time > (classic space vs cpu tradeoff). > Whether that's applicable here, dunno.] > > We do record with symbols the line number provided by the debug info. > The problem for variables and types is that we don't, AFAICT, > provide the user a nice way to display it. > > I tried "list var" and "list type" and saw it working for some objects > and not for others (didn't dig into why yet). > At any rate, what if "list counter" worked? > Another thought is to extend "info line" to take variables and types. > Or add a new command if people are wedded to "list" and "info line" > not working with non-linespec things. Or we could extend what > a linespec can refer to, but it's kinda nice to associate linespecs > with things that have pc addresses. > > Another thought is to provide the ability to include > source location in ptype output. [for reference sake] I happened upon this bug, looking up "info type" bugs for something else. https://sourceware.org/bugzilla/show_bug.cgi?id=11796