|Areas||interpreter back-end, command dispatch, nre, debugging|
|Good if student knows||C (essential) and gdb|
|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|
The Tcl core 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
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)