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.
