Re: [Nemiver-list] Viewing Global/Static Variables

[Dodji <dodji domain hid>]

Hello,

> Currently nemiver lists on local variables and function arguments.
> I would like to add code to display global and static variables.

Okay.

> There's an "mi" command that's called "-symbol-list-variables" which
> should display global and static variables. Unfortunately, it's not
> implemented (at least on my GDB, version 6.4.90-debian).

Right, quite a number of GDB mi commands are not yet implemented, unfortunately.

> So I'll have to resort to "info variables" gdb command which lists
> global and static variables.

Okay.
>
> 1. add "list_global_variables()" to class "GDBEngine", which queue this
> command.

Okay.

> 2. add "OnGlobalVariablesListedHandler" struct (which will be very
> similar to "OnLocalVariablesListedHandler"), to parse the output of
> "info variables", and emit signal for each variable.

Yes, this is the way to go.

Just to make things clear, I'd like to add a little something.

The debugger output is actually not parsed in an output handler.
Output handlers are child classes of  nemiver::OutputHandlers (like
OnLocalVariableListedHandler). Debugger outputs are automatically
parsed by the GDBEngine type. The result of the parsing is an instance
of nemiver::Output, and is actually an abstract syntax tree modeled
after the mi type "output". This output is passed to the list of
output handlers that have been registered into the GDBEngine,
previously. Each output engine is then responsible to analyse the
Output
 and fire signals to notify the world about the occurrence of a
particular event like "local variable list available" or things like
that.

So I agree with you. Doing this is the way to go.

> 3. in "LocalVarsInspector" class, add a single call to
> "list_global_variables". since global  variables don't appear or
> disappear, only one such call is needed (unlike "list_local_variables",
> which is called on every "stopped" signal).

Okay this is the tricky bit, as Jonner was pointing in his email
https://mail.gna.org/public/nemiver-list/2007-09/msg00001.html .

Today, browsing variable in a widget is a bit messy because the widget
is responsible of dealing with the asynchronous nature of the
IDebugger interface. The widget issues a command, waits for IDebugger
to notify when the command responds etc ...
GDB does not really allow to get all the variables with all their
contents. It is really when the user clicks on a given variable in the
widget that several commands are issued to get the content and type of
the variable. When that variable is compound, you can imagine the pain
it is to deal with that in an asynchronus way ...

So I am seriously thinking about a variable object model (VOM) that
would hide that complexity away from the widget, The widget would use
the VOM to iterate over variable and their content. I will post more
on this topic here when I have a clearer view on it myself :-)

So I think you could start with points 1/ and 2/ and I will come back
to you when I have more fruits regarding the VOM :-)

> 4. Every global variable will be queried to it's type and value on every
> "stopped" signal.

Sure, this would be the way to go. I am just a bit worried about the
cost of this operation because usually there are a lot of global
variables in a program :-) But well, we have to do it and then when
will see how to optimize things.

>
> note: "info variables" lists many global variables, some of which are
> internal to glibc and are totally uninteresting. they are also marked
> under the title "Non-debugging symbols" so these variables will not be
> displayed.

Exactly. We will also need to decide where the "discrimination" about
what to show or not should be made ...

>
> Comments are welcomed,
>
Well, I am delitghted to see someone else, besides Jonner and I,
digging in nemiver code :-)
It also seems you are getting a good grasp at the code, congratulations :-)

Please do not hesitate to ask technical questions on this list, we are
here for that.

What else could I say ? Ah, yes, you are welcome :-)

Cheers,

Dodji.
-- 
Dodji Seketeli
http://www.seketeli.org/dodji