With much trepidation, recently I started porting my trepanning debugger to Perl. Perl has always had a really good debugger, so said above, I undertook this with some hesitation.
As someone who doesn't always work in Perl, the stock Perl debugger, perl5db.pl has always felt to me a little bit of a one off. For example, I can't think of another debugger that uses T to show a backtrace, and backtraces in debuggers usually include the point where one is stopped. The fact that there are no frame switching commands (in gdb: "up", "down", and "frame") may be related to the fact that evaluation in Perl's debugger works only on the top-most frame. But even given this, I think this not having frame switching commands is a misguided decision since frame switching is also useful for things like setting breakpoints or listing code. So one motivation for writing a debugger (or rewriting per5db or porting the Ruby trepanning debugger - take your pick) was to provide more gdb-like commands. Another goal was to have something a little more modular and testable. And a third was to provide some of the things I think are cool in the trepanning debugger that I think are lacking in perl5db. Although the work is far from complete, already there are things in there I think cool. For example code is syntax highlighted via Syntax::Highlight::Perl::Improved. (I haven't put in the "list" command though.) There is Readline debugger command completion. One of the cool kinds of completion is on the "eval" command where the current line of source will be filled in. There is an eval? command which I've found useful in stripping off common expression parts of a statement. For example eval? of "return foo(a,b,c)" would be foo(a,b,c). Or eval? of "my $x=foo(a,b,c)" would be evaluate "$x = foo(a,b,c)"; eval? of "if ($x > 5) {" would be "($x > 5)". And so on. When something is evaluated the return value is saved in a global array in the DB namespace. Since eval context determines how something is evaluated, there are commands for evaluating an expression either in a hash, array and scalar context. (See eval@ eval$ and eval% with command aliases @, $ and %). The way the code is currently structured, commands reside in a "command" directory and each command is a file/module in that directory. Given this, it's possible for users to add their own commands in a user command directory. And although I don't intend on doing this, it would be possible to just redo the existing perl5db commands using the Trepanning command framework. The advantage here is that commands would be included in command completion and documented in the help system. Oh, did I mention that rather extensive help is available for each command, and that you can list categories of commands as is done in gdb? Ok. Enough advertising. The code resides on github right now in https://github.com/rocky/Perl-Devel-Trepan. It'll make its way to CPAN as a package at some point. There are still a number of things to add before general release, but so far what needs adding is just SMOP (small matter of programming): code and tests to be ported from the Ruby trepanning debugger or adapted from perl5db.