source: trunk/essentials/dev-lang/perl/pod/perldebguts.pod@ 3609

=head1 NAME

perldebguts - Guts of Perl debugging 

=head1 DESCRIPTION

This is not the perldebug(1) manpage, which tells you how to use
the debugger.  This manpage describes low-level details concerning
the debugger's internals, which range from difficult to impossible
to understand for anyone who isn't incredibly intimate with Perl's guts.
Caveat lector.

=head1 Debugger Internals

Perl has special debugging hooks at compile-time and run-time used
to create debugging environments.  These hooks are not to be confused
with the I<perl -Dxxx> command described in L<perlrun>, which is
usable only if a special Perl is built per the instructions in the
F<INSTALL> podpage in the Perl source tree.

For example, whenever you call Perl's built-in C<caller> function
from the package C<DB>, the arguments that the corresponding stack
frame was called with are copied to the C<@DB::args> array.  These
mechanisms are enabled by calling Perl with the B<-d> switch.
Specifically, the following additional features are enabled
(cf. L<perlvar/$^P>):

=over 4

=item *

Perl inserts the contents of C<$ENV{PERL5DB}> (or C<BEGIN {require
'perl5db.pl'}> if not present) before the first line of your program.

=item *

Each array C<@{"_<$filename"}> holds the lines of $filename for a
file compiled by Perl.  The same is also true for C<eval>ed strings
that contain subroutines, or which are currently being executed.
The $filename for C<eval>ed strings looks like C<(eval 34)>.
Code assertions in regexes look like C<(re_eval 19)>.

Values in this array are magical in numeric context: they compare
equal to zero only if the line is not breakable.

=item *

Each hash C<%{"_<$filename"}> contains breakpoints and actions keyed
by line number.  Individual entries (as opposed to the whole hash)
are settable.  Perl only cares about Boolean true here, although
the values used by F<perl5db.pl> have the form
C<"$break_condition\0$action">.  

The same holds for evaluated strings that contain subroutines, or
which are currently being executed.  The $filename for C<eval>ed strings
looks like C<(eval 34)> or  C<(re_eval 19)>.

=item *

Each scalar C<${"_<$filename"}> contains C<"_<$filename">.  This is
also the case for evaluated strings that contain subroutines, or
which are currently being executed.  The $filename for C<eval>ed
strings looks like C<(eval 34)> or C<(re_eval 19)>.

=item *

After each C<require>d file is compiled, but before it is executed,
C<DB::postponed(*{"_<$filename"})> is called if the subroutine
C<DB::postponed> exists.  Here, the $filename is the expanded name of
the C<require>d file, as found in the values of %INC.

=item *

After each subroutine C<subname> is compiled, the existence of
C<$DB::postponed{subname}> is checked.  If this key exists,
C<DB::postponed(subname)> is called if the C<DB::postponed> subroutine
also exists.

=item *

A hash C<%DB::sub> is maintained, whose keys are subroutine names
and whose values have the form C<filename:startline-endline>.
C<filename> has the form C<(eval 34)> for subroutines defined inside
C<eval>s, or C<(re_eval 19)> for those within regex code assertions.

=item *

When the execution of your program reaches a point that can hold a
breakpoint, the C<DB::DB()> subroutine is called if any of the variables
C<$DB::trace>, C<$DB::single>, or C<$DB::signal> is true.  These variables
are not C<local>izable.  This feature is disabled when executing
inside C<DB::DB()>, including functions called from it 
unless C<< $^D & (1<<30) >> is true.

=item *

When execution of the program reaches a subroutine call, a call to
C<&DB::sub>(I<args>) is made instead, with C<$DB::sub> holding the
name of the called subroutine. (This doesn't happen if the subroutine
was compiled in the C<DB> package.)

=back

Note that if C<&DB::sub> needs external data for it to work, no
subroutine call is possible without it. As an example, the standard
debugger's C<&DB::sub> depends on the C<$DB::deep> variable
(it defines how many levels of recursion deep into the debugger you can go
before a mandatory break).  If C<$DB::deep> is not defined, subroutine
calls are not possible, even though C<&DB::sub> exists.

=head2 Writing Your Own Debugger

=head3 Environment Variables

The C<PERL5DB> environment variable can be used to define a debugger.
For example, the minimal "working" debugger (it actually doesn't do anything)
consists of one line:

  sub DB::DB {}

It can easily be defined like this:

  $ PERL5DB="sub DB::DB {}" perl -d your-script

Another brief debugger, slightly more useful, can be created
with only the line:

  sub DB::DB {print ++$i; scalar <STDIN>}

This debugger prints a number which increments for each statement
encountered and waits for you to hit a newline before continuing
to the next statement.

The following debugger is actually useful:

  {
    package DB;
    sub DB  {}
    sub sub {print ++$i, " $sub\n"; &$sub}
  }

It prints the sequence number of each subroutine call and the name of the
called subroutine.  Note that C<&DB::sub> is being compiled into the
package C<DB> through the use of the C<package> directive.

When it starts, the debugger reads your rc file (F<./.perldb> or
F<~/.perldb> under Unix), which can set important options.
(A subroutine (C<&afterinit>) can be defined here as well; it is executed
after the debugger completes its own initialization.)

After the rc file is read, the debugger reads the PERLDB_OPTS
environment variable and uses it to set debugger options. The
contents of this variable are treated as if they were the argument
of an C<o ...> debugger command (q.v. in L<perldebug/Options>).

=head3 Debugger internal variables
In addition to the file and subroutine-related variables mentioned above,
the debugger also maintains various magical internal variables.

=over 4