Implementing Debuggers - oils-for-unix/oils GitHub Wiki

What is a trepanning debugger?

Reply from Rocky Bernstein:

This is a term I made up to mean the class of gdb-like debuggers that I've written.

[I rewrote Python's pydb more or less from scratch] and called it Python pydbgr. When I got to Poland to give a talk on doing the same for Ruby, the Poles told me that my name pydbgr was totally unpronouncable and doesn't have enough vowels!

Ouch! When a Pole tells you this, you know you've done something wrong!

At that point, I asked for help from a friend, Mike Welles. He came up with the term "Trepanning". It is an old medical practice of drilling a hole in your head to release the bad vapors.

  • Debuggers in Dynamic Languages (pdf) at DYLA 2010

    • I suggest a modular program structure for a debugger that I have been using. However first, I describe some of the support features which are commonly missing. These are: (1) better position information for dynamically generated code, e.g., from a method defined by a string variable in a program or coming from a data structure representing some code; (2) verification that source code matches the object code; and (3) better, faster support for breakpoints, “step over” and “step into.”

  • Bash Debugger: History and Acknowledgements. Interesting story behind getting the hooks into bash! bash 2.05 was released in 2002.

    • In version 2.04 of BASH, Rocky Bernstein started hacking on BASH to add call-stack information, source file information, allow for debugging into functions and for reporting line numbers in functions as relative to the file rather than the beginning of a function whose origin line number was not accessible from BASH. He started changing the user commands in bashdb to be like other more-advanced debuggers, in particular perl5db and gdb. However he gave up on this project when realizing that stopping before a line was crucial. A patch for this was nontrivial and wildly changed semantics. Furthermore the chance of getting his other patches into BASH was was not going to happen in version 2.04.
    • In version 2.05, the fundamental necessary change to the semantics of SIGDEBUG trap handling (suggested at least two years earlier) was made. Also, version 2.05 changed the line-number reporting in a function to be relative to the beginning of the file rather than the beginning of a function—sometimes. Rocky then picked up where he left off and this then became this debugger. A complete rewrite of the debugger, some of which started in 2.04 was undertaken. Debugger internals were changed to support multiple file names, save and restore the calling environment (such as variables $1 and $?) and install debugger signal handlers. Work was also done on the BASH in conjunction with the debugger to save stack trace information, provide a means for stopping after a routine finished, debugging into a subshell and so on. And a number of changes were made to BASH just to improve the accuracy of the line number reporting which is crucial in a debugger.

  • https://wiki.ubuntu.com/DebuggerTalk - by Rocky Bernstein

Projects

CPython