- Prompt
-
The debugger prompt is something like
or even
where that number is the command number, and which you'd use to access with the built-in csh-like
history mechanism. For example, !17 would repeat command number 17. The depth
of the angle brackets indicates the nesting depth of the debugger. You could get more than
one set of brackets, for example, if you'd already at a breakpoint and then printed the
result of a function call that itself has a breakpoint, or you step into an expression via s/n/t
expression command.
- Multiline commands
-
If you want to enter a multi-line command, such as a subroutine definition with several
statements or a format, escape the newline that would normally end the debugger command with
a backslash. Here's an example:
DB<1> for (1..4) { \
cont: print "ok\n"; \
cont: }
ok
ok
ok
ok
|
|
Note that this business of escaping a newline is specific to interactive commands typed
into the debugger.
- Stack backtrace
-
Here's an example of what a stack backtrace via T command might look like:
$ = main::infested called from file `Ambulation.pm' line 10
@ = Ambulation::legs(1, 2, 3, 4) called from file `camel_flea' line 7
$ = main::pests('bactrian', 4) called from file `camel_flea' line 4
|
|
The left-hand character up there indicates the context in which the function was called,
with $ and @ meaning scalar or list contexts respectively, and .
meaning void context (which is actually a sort of scalar context). The display above says
that you were in the function main::infested when you ran the stack dump, and
that it was called in scalar context from line 10 of the file Ambulation.pm, but
without any arguments at all, meaning it was called as &infested. The next
stack frame shows that the function Ambulation::legs was called in list context
from the camel_flea file with four arguments. The last stack frame shows that main::pests
was called in scalar context, also from camel_flea, but from line 4.
If you execute the T command from inside an active use
statement, the backtrace will contain both a require frame and an eval)
frame.
- Line Listing Format
-
This shows the sorts of output the l command can produce:
DB<<13>> l
101: @i{@i} = ();
102:b @isa{@i,$pack} = ()
103 if(exists $i{$prevpack} || exists $isa{$pack});
104 }
105
106 next
107==> if(exists $isa{$pack});
108
109:a if ($extra-- > 0) {
110: %isa = ($pack,1);
|
|
Breakable lines are marked with :. Lines with breakpoints are marked by b
and those with actions by a. The line that's about to be executed is marked by ==>.
Please be aware that code in debugger listings may not look the same as your original
source code. Line directives and external source filters can alter the code before Perl sees
it, causing code to move from its original positions or take on entirely different forms.
- Frame listing
- When the
frame option is set, the debugger would print entered (and
optionally exited) subroutines in different styles. See perldebguts for incredibly
long examples of these.
|
|
