"Local Variables" window broken on MIPS?

"Local Variables" window broken on MIPS?

[Ivan Horvat]

Hi.

I'm having problems with insight 6.0 release and as well with snapshot
20030516. When debugging c++ programs, the "Local Variables" button
(or CTRL-L) opens an empty window. On the other side, when I'm hovering
with mouse over the variables in the Source Window, the values in the
balloon window appear ok. Insight is configured as --host=i686-pc-linux-gnu
--target=mipsel-vr4100-elf. Natively, everything works well.

At first, there was a "local variables" issue with gdb 5.3 and 6.0
(configured exactly as Insight, for MIPS target) when debugging c++ 
programs.
For the fragments of code like this one:

   for(int i = 0; i < N; i++){
      int j;
      j = i*N + i;
      ...
   }

trying to print 'i' or 'j' resulted in <<No symbol "i" in current context>>
error. I found a simple fix for that and applied it to insight source tree.
This enabled insight to print correct values while hovering over them or
adding them to the Watch window, but "Local Variables" button is still
broken. That surprises me because I assumed that the hovering over the
variable in Insights' GUI calls the same gdb internal functions as, for
example, typing "print var" in console. So, I assumed that pressing the
"Local Variables" button would trigger the same piece of code as typing
"info locals" in console...
But "info locals" works very well, while Insight shows an empty window.

Can someone please point me to the gdb function(s) called when the
"Local Variables" button is pressed, or explain to me how actually Insight
communicates with gdb? I suspect that my fix for gdb isn't complete, and 
that
there still may be broken parts of gdb that I'm unaware of. Maybe
"Local Variables" button hits one of these parts?


Regards,
Ivan Horvat.

Re: "Local Variables" window broken on MIPS?

[Keith Seitz]

On Wed, 2004-01-28 at 12:25, Ivan Horvat wrote:
> Can someone please point me to the gdb function(s) called when the
> "Local Variables" button is pressed, or explain to me how actually Insight
> communicates with gdb? I suspect that my fix for gdb isn't complete, and 
> that
> there still may be broken parts of gdb that I'm unaware of. Maybe
> "Local Variables" button hits one of these parts?

First thing to try: run the varobj testsuite. You can do this by doing
(in your gdb build directory):

$ make RUNTESTFLAGS="mi-var-block.exp mi-var-display.exp
mi-var-child.exp mi-var-cmd.exp" check

Next, run Insight's testsuite on c_variable.exp and cpp_variable.exp.
(You do this by using the same command as above.)

If there are no failures there, then you're into the nitty gritty of it.
When you are at a point in your code where Insight exhibits this
incorrect behavior, open a console window and type "info locals". Does a
list of the local variables appear?

If they do, what does the command "tk gdb_block_variables START END"
give the same list? (You need to provide the start and end address of
the current frame: use "info frame" to find them).

If they do not, you have found a gdb bug. Send a note to the gdb list.

FYI, within the Locals Window, the list of variables in scope comes from
the Tcl command Block::_findVariables. It calls the interpreter command
gdb_block_variables, which is defined in gdb_block_vars in gdbtk-stack.c
(src/gdb/gdbtk/generic). This function be reminiscent of gdb's "info
locals" command, and they should be similar. It is possible that changes
were made to "info locals" but not gdb_block_vars.

[As you've probably guessed, no one is really working on insight
anymore. I've given up trying to keep up with the sweeping changes that
gdb's fifty developers put in nightly. I cannot/will not do it alone. I
have other interests in life.]

Send mail to the list if you discover anything. Good luck.
Keith