Getting the "description" of a variable

Getting the "description" of a variable

[Siva Chandra]

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?

Thanks,
Siva Chandra

Re: Getting the "description" of a variable

[Doug Evans]

On Thu, Dec 18, 2014 at 5:00 PM, Siva Chandra <sivachandra@google.com> 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.

Re: Getting the "description" of a variable

[Doug Evans]

On Fri, Jan 2, 2015 at 2:26 PM, Doug Evans <dje@google.com> wrote:
> On Thu, Dec 18, 2014 at 5:00 PM, Siva Chandra <sivachandra@google.com> 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