| 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, gain experience with scripting debuggers, eternal recognition |
| Benefits to Tcl | Easier debugging of the Tcl core |
| Mentor | Miguel Sofer |
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
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)