Re: Getting the "description" of a variable

On Fri, Jan 2, 2015 at 2:26 PM, Doug Evans <[email protected]> wrote:
> On Thu, Dec 18, 2014 at 5:00 PM, Siva Chandra <[email protected]> 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