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.