%|||%
&|Areas| interpreter back-end, command dispatch, nre, debugging |&
&|Good if student knows | C (essential) and gdb |&
&|Priority| high |&
&|Difficulty| Medium (C skills required) |&
&|Benefits to the student| Learn Tcl and C internals, language design and implementation, experience with scripting debuggers, eternal recognition |&
&|Benefits to Tcl| Easier debugging of the Tcl core |&
&|Mentor| [Miguel Sofer] |&

**Project Description**

Tcl has become a lot harder to debug since [NRE]'s adoption. The problem is intrinsic to the nature and goals of the [NRE]: [C] keeps a ''who called me stack'', [NRE] does its best to replace it with a ''who do we call next stack''. But

   * Most debugging tools like [gdb] are designed for C
   * Bug analysis requires understanding the path that leads to failure, not so much what would have happened after that

Tcl is a ''lispy'' language built onto C - a 100% procedural substrate. The [NRE] is a mechanism that enables features like coroutines and proper tailcalls. 

All's well when all's well, but when things go boom in the night the tools designed for C get lost too. Today the only way to understand what is happening is a tedious manual inspection of the [NRE] stack, which allows to deduce the execution history if there were no intervening tailcalls. It is hard work that requires a lot of concentration and knowledge of the internals.

The student will have to gain a good understanding of the flow of control in Tcl's internals. Armed with this, s/he will research different possibilities for assisting the developer to debug Tcl's core, including a simpler inspection of core dumps, and implement one of them. One idea might be to devise a tracing mode, enabled with special compile flags, that would maintain a ''who called me stack'' (in memory? on file?). 

A second step would then be to arrange for the tracing output to be inspected from [gdb] ([MS]: I cannot estimate the difficulty of this step, as I have no knowledge of [gdb] except as unsophisticated user)


**References**

   * ''The Debugging Scandal and What to Do About It'' [http://web.media.mit.edu/~lieber/Lieberary/Softviz/CACM-Debugging/CACM-Debugging-Intro.html#Intro]
   * ''Scripted Debugging : Using Tcl and GDB to debug C code'' [http://www.tcl.tk/community/tcl2004/Tcl2003papers/dejong.pdf]

**Comments**

<<categories>> GSoC | Debugging