It is a painful reality that when looking at the Tcl code and debugging Tcl level stuff, one wants to get at the C-level classes, and vice versa. This is a smallish hint on how one can make that task easier. If you are running ns through gdb, then the following incantation (shown below) gets you access to the Tcl debugger. Notes on how you can then use this debugger and what you can do with it are documented earlier in this chapter and at this URL (http://expect.nist.gov/tcl-debug/tcl-debug.ps.Z).
(gdb) run Starting program: /nfs/prot/kannan/PhD/simulators/ns/ns-2/ns ... Breakpoint 1, AddressClassifier::AddressClassifier (this=0x12fbd8) at classifier-addr.cc:47 (gdb) p this-\>name\_ \$1 = 0x2711e8 "\_o73" (gdb) call Tcl::instance().eval("debug 1") 15: lappend auto\_path \$dbg\_library dbg15.3\> w *0: application 15: lappend auto\_path /usr/local/lib/dbg dbg15.4\> Simulator info instances \_o1 dbg15.5\> \_o1 now 0 dbg15.6\> # and other fun stuff dbg15.7\> \_o73 info class Classifier/Addr dbg15.8\> \_o73 info vars slots\_ shift\_ off\_ip\_ offset\_ off\_flags\_ mask\_ off\_cmn\_ dbg15.9\> c (gdb) w Ambiguous command "w": while, whatis, where, watch. (gdb) where #0 AddressClassifier::AddressClassifier (this=0x12fbd8) at classifier-addr.cc:47 #1 0x5c68 in AddressClassifierClass::create (this=0x10d6c8, argc=4, argv=0xefffcdc0) at classifier-addr.cc:63 ... (gdb)
In a like manner, if you have started ns through gdb, then you can always get gdb's attention by sending an interrupt, usually a Ctrl-c on berkeloidrones. However, note that these do tamper with the stack frame, and on occasion, may (sometimes can (and rarely, does)) screw up the stack so that, you may not be in a position to resume execution. To its credit, gdb appears to be smart enough to warn you about such instances when you should tread softly, and carry a big stick.
Tom Henderson 2011-11-05