%|||% &|Areas| ??? |& &|Good if student knows | ??? |& &|Priority| ??? |& &|Difficulty| Medium (C skills required) |& &|Benefits to the student| ??? |& &|Benefits to Tcl| ??? |& &|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 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 would 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** **Comments** <> GSoC | Debugging