From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25708 invoked by alias); 2 Jan 2015 22:26:33 -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 25695 invoked by uid 89); 2 Jan 2015 22:26:32 -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-f169.google.com Received: from mail-ob0-f169.google.com (HELO mail-ob0-f169.google.com) (209.85.214.169) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 02 Jan 2015 22:26:30 +0000 Received: by mail-ob0-f169.google.com with SMTP id vb8so54592373obc.0 for ; Fri, 02 Jan 2015 14:26:28 -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=VZ2JaJEZGUCMzmiT43XqO8R1ei+pld5mAF+zYK6biXg=; b=m+Nnrtbgq+EGVfukFW0SywBDvCTriP35n8VIjqD/vWRvDj80rfxGrJay4Kx75nrK8K zSYM+vSM6Z/u/69atGryGVZ15F1pcbP0nyj4IoSYQfb40ThNZxI8j2+rkuqQdUYJpr0R rNP63zxfSSQXFZf3/vFq6enWw2PX2NkaY0wH7vA2OLKrkH4SpLRzrLKvnxfq1xqWn7K4 +MdlMRaaTbepLo2nK2kcZyJFB/IFmlQKRg91O+jO7SatdqNpf+jYhO1ci5T7mko0QC7m FA49qzCbRHECbSesW0QZG4sSVayMInGc+oZYCU0tLIkuWMTbAdnOXC/+EDYQzkQjT/8f vKWg== X-Gm-Message-State: ALoCoQl+EQCxgKlYKM9GsPU9UR9FihXLoUeDBD4u9VUlVwcHmkapSKdR/B4ZSnNHCO4qMIP7dv2B MIME-Version: 1.0 X-Received: by 10.202.61.9 with SMTP id k9mr43926922oia.116.1420237588822; Fri, 02 Jan 2015 14:26:28 -0800 (PST) Received: by 10.182.222.98 with HTTP; Fri, 2 Jan 2015 14:26:28 -0800 (PST) In-Reply-To: References: Date: Fri, 02 Jan 2015 22:26: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/msg00010.txt.bz2 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.