This is the mail archive of the insight@sources.redhat.com mailing list for the Insight project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: untangling c & tcl code


On Wed, 13 Feb 2002, Duane Ellis wrote:

> Does anybody have a good solution to debugging (er, untangling, and
> understanding) how tk and tcl interact with GDB.

I'm sure it's nothing ideal, but, well, here's what I do...

> My problem:
>
>    When I need to figure out how something works I use a debugger to
>    step through the C code. But then... GDB calls some TK/TCL script
>    function and I cannot step through that portion in any productive
>    way.
>
>    Oh yea, I can see that the code is calling the cached pre-compiled
>    bytecode for something.... Just what... is next to impossible
>    to figure out.

You're using code from 1998.. Hmm. If that has itcl3.0 and a bunch of
share/gdbtcl/*.ith and *.itb files, your in good shape. Itcl3.0 allows you
to resource classes at runtime (but you cannot redefine the class: no
adding/removing methods, proc, public/private/protected variables, etc).
If not, well, you'll have to restart Insight every time. :-(

Insight is split into to large chunks of code (as you already know): the C
code and the Tcl code. We have commands added to the tcl interpreter to
bridge these two environments.

Now when a problem occurs, the first thing I check is whether it is just a
display problem, i.e., is Tcl (code) getting the right data or is it
displaying it incorrectly?

Using the "tk" command in the console window, I run the code that gets the
data from gdb's internals. If the data is correct, I know I've got a tcl
code problem, and I insert a bunch of "dbug" statements to figure out what
is wrong. This is very easy to do, since Itcl3.0 allows us to do this.
Simply use the debug window to resource the file. If you need to debug a
*.tcl or *.itcl file, well, then you may be out of luck, but not usually.

If the data from C-land is incorrect, it's time to use a debugger and
figure out why. I set a breakpoint on the function that the tcl code calls
and go from there.

To date, I've never needed to be able to debug both C code and Tcl code at
the same time. (Or at least I've done it so few times that I don't recall
having to do it!)

At one time we had some code to use the TclPro debugger. I don't know if
it still works. (This is only an alternative to using dbug statements.)
I've also had good luck using tkcon on unix to do some runtime debugging,
too.

If you ever get stuck, just send out a note with some details, and maybe
we can help corrupt^Wchange your debugging paradigm. ;-)

Keith



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]