nredebugging

This page is about (the features that should be produced within) an ongoing project of the Google Summer Of Code 2011.

The idea (abstractly): Tcl interpreter uses internally its own call stack stored in the heap to save C stack space. This project's goal is to ease debugging of tcl interpreter by means of implementing additional Gdb commands.

General

• Title: Debugging tools for NRE
• Student: Krzysztof Kwaśniewski
• Mentor: Miguel Sofer
• Repository: http://fossil.msofer.com/nredebug/home (at the moment some technical problems)
• Repository 2: http://chiselapp.com/user/krzykwas/repository/nredebug1

Short description

Provided from the proposal:

The aim of the project is to ease debugging of Tcl interpreter’s internal call stack, which Gdb is unaware of and thus gives no help with examining it. The call stack is implemented as a linked list and as for now in case of a crash the developer browses it by hand, pointer by pointer, to find out the grounds of the failure. As I have discussed the project with the mentor, Miguel Sofer, following tasks were defined:

1. To ease debugging, a couple of gdb commands should be implemented and the first step is to find out how to do it - using a scripted extension, loadable module or source patch. This step is partially finished, although it needs more investigation. It is possible to implement a gdb extension in Tcl. Providing any obstacles follow, it is also possible in Python. Moreover, there exists another possibility - one can script Gdb, although it is likely to be less powerful than Tcl or Python extensions.
2. Understand the tcl/nre flow and design tools needed to examine the interpreter’s state. The exact functionality is an open question for now as I have to investigate the interpreter’s internals first to be able to discuss the requirements with my mentor and Tcl community. Nevertheless the implemented commands must allow the developer to set breakpoints and print the call stack contents with various criteria.
3. Devise possible Tcl interpreter’s modifications allowing better examination of its state. Depending on their impact on the performance, they can be enabled only with special compilation flags.
4. Prepare documentation describing the implemented Gdb commands. Up till now its form is not decided yet.

Progress

Before the official coding time

• Before 4.05: The assumption about possibility of extending Gdb with Tcl was partially wrong, it's possible only in a special Gdb version prepared for VxWorks. Apart from that I have found GDBMI library by Moses DeJong allowing to communicate between Tcl and Gdb. So still there exists an option to use Tcl. I have experimented with both most promising ways of extending Gdb.
  • The first one is Python support built into Gdb. Adding commands in that way is quite simple and there is some documentation on that. This solution seems to be quite robust and it will be probably developed in the future.
  • The other option is to use GDBMI. I have run it and have found how to do some basic things, the most important being able to pass raw commands to gdb and get the output, so it is possible to keep all the gdb commands and implement several new. Unfortunaltely, GDBMI hasn't been developed for a couple of years.

The difference between this both two options is also connected with a way in which the debugging would work. The Python solution doesn't change much, but the GDBMI one would need to wrap Gdb with a Tcl program. It may or may not require to update the Tcl program with each new Gdb version. I have not decided yet what to choose, though the first version seems to be more robust. Please give any comments or opinions you may have on this issue. Maybe there is a way of extending Gdb that I haven't found. Please, write about it.

• 4.05: The repository is set up thanks to the help of Miguel Sofer.
• 4.05: It is planned in a short time (like days) to start gathering the requirements. Up till now Gustaff Neumann has proposed to parse and display clientData contents depending on the function with this pointer as an argument and also to examine/disassemble the bytecode. I will order the ideas in future, as for now I can say the Gdb commands will be scheduled first.
• 20.05: The first things to implement are:
  • nre-bt (navigation on the tcl stack, partially implemented)
  • nre-f (position on selected frame)
  • nre-p (print selected callback with proper casts)

During the official coding time

• Until 10.06: Many duties at my university have caused some delay. For a couple last days I have done quite much, so summing it up the present state is:
  • nre-bt, nre-cmds, nre-idx, nre-top implemented with different approach about what information about each callback to display
  • implemented client data parsing
  • several unit tests added

nre-bt displays the stack with little details. nre-cmds displays NRCommands in the same manner, though if there are only a couple of them, more details are presented. nre-idx shows n-th callback and nre-top means „nre-idx 0”. Client data is parsed according to simple format strings provided in an external file. The next aim is to implement additional I/O channel allowing to further extend gdb with external programs.

• 13.06: There is no need for any special path to run the code, however „locate” has to be updated.
• Until 16.06: Refactorization of the code, improvements among unit tests, updated command help, I/O channels partially supported.
• 17.06:
  • Auto-completion for channel-run command's arguments
  • Finished implementation of I/O channels. Now one can develop any extension for gdb in any language using simple text protocol based on standard I/O streams. The gdb's text-interface is retained, so the implementation is easy and simple.
• Until 21.06: Further channel improvements, changes in numbering frames for nre-cmds.
• Until 25.06: Several errors fixed, code enhancements.
• The channels are implemented, however they ought to be tested by a different person (not me) with a particular focus on ease of usage. As for now there exist three gdb commands designed for working with channels, these are: channel-add, channel-list and channel-run. The simple protocol now consist of a couple of commands:
  • end: finish communication
  • print: write the argument as a string to the user
  • exec: execute the argument as a gdb command and return the result between „begin_output” and „end_output”

The protocol may be further extended according to the needs of its (future) users.

• There exists a way of auto-loading channels: programs placed in a special directory are run at start-up. This way a kind of a new gdb command may be added in a most convenient way for the user.
• Callback's client data formatted according to the contents of nredata_hints.py file which contains formatting strings inside. Eventually the formatting strings are to be provided using some macros in tcl code.