-If you have GNU B<emacs> installed on your system, it can interact with
-the Perl debugger to provide an integrated software development
-environment reminiscent of its interactions with C debuggers.
-
-Perl is also delivered with a start file for making B<emacs> act like a
-syntax-directed editor that understands (some of) Perl's syntax. Look in
-the I<emacs> directory of the Perl source distribution.
-
-(Historically, a similar setup for interacting with B<vi> and the
-X11 window system had also been available, but at the time of this
-writing, no debugger support for B<vi> currently exists.)
-
-=head2 The Perl Profiler
-
-If you wish to supply an alternative debugger for Perl to run, just
-invoke your script with a colon and a package argument given to the B<-d>
-flag. One of the most popular alternative debuggers for Perl is
-B<DProf>, the Perl profiler. As of this writing, B<DProf> is not
-included with the standard Perl distribution, but it is expected to
-be included soon, for certain values of "soon".
-
-Meanwhile, you can fetch the Devel::Dprof module from CPAN. Assuming
-it's properly installed on your system, to profile your Perl program in
-the file F<mycode.pl>, just type:
-
- perl -d:DProf mycode.pl
-
-When the script terminates the profiler will dump the profile information
-to a file called F<tmon.out>. A tool like B<dprofpp> (also supplied with
-the Devel::DProf package) can be used to interpret the information which is
-in that profile.
-
-=head2 Debugger support in perl
-
-When you call the B<caller> function (see L<perlfunc/caller>) from the
-package DB, Perl sets the array @DB::args to contain the arguments the
-corresponding stack frame was called with.
-
-If perl is run with B<-d> option, the following additional features
-are enabled (cf. L<perlvar/$^P>):
-
-=over
-
-=item *
-
-Perl inserts the contents of C<$ENV{PERL5DB}> (or C<BEGIN {require
-'perl5db.pl'}> if not present) before the first line of the
-application.
-
-=item *
-
-The array C<@{"_E<lt>$filename"}> is the line-by-line contents of
-$filename for all the compiled files. Same for C<eval>ed strings which
-contain subroutines, or which are currently executed. The $filename
-for C<eval>ed strings looks like C<(eval 34)>.
-
-=item *
-
-The hash C<%{"_E<lt>$filename"}> contains breakpoints and action (it is
-keyed by line number), and individual entries are settable (as opposed
-to the whole hash). Only true/false is important to Perl, though the
-values used by F<perl5db.pl> have the form
-C<"$break_condition\0$action">. Values are magical in numeric context:
-they are zeros if the line is not breakable.
-
-Same for evaluated strings which contain subroutines, or which are
-currently executed. The $filename for C<eval>ed strings looks like
-C<(eval 34)>.
-
-=item *
-
-The scalar C<${"_E<lt>$filename"}> contains C<"_E<lt>$filename">. Same for
-evaluated strings which contain subroutines, or which are currently
-executed. The $filename for C<eval>ed strings looks like C<(eval
-34)>.
-
-=item *
-
-After each C<require>d file is compiled, but before it is executed,
-C<DB::postponed(*{"_E<lt>$filename"})> is called (if subroutine
-C<DB::postponed> exists). Here the $filename is the expanded name of
-the C<require>d file (as found in values of %INC).
-
-=item *
-
-After each subroutine C<subname> is compiled existence of
-C<$DB::postponed{subname}> is checked. If this key exists,
-C<DB::postponed(subname)> is called (if subroutine C<DB::postponed>
-exists).
-
-=item *
-
-A hash C<%DB::sub> is maintained, with keys being subroutine names,
-values having the form C<filename:startline-endline>. C<filename> has
-the form C<(eval 31)> for subroutines defined inside C<eval>s.
-
-=item *
-
-When execution of the application reaches a place that can have
-a breakpoint, a call to C<DB::DB()> is performed if any one of
-variables $DB::trace, $DB::single, or $DB::signal is true. (Note that
-these variables are not C<local>izable.) This feature is disabled when
-the control is inside C<DB::DB()> or functions called from it (unless
-C<$^D & (1E<lt>E<lt>30)>).
-
-=item *
-
-When execution of the application reaches a subroutine call, a call
-to C<&DB::sub>(I<args>) is performed instead, with C<$DB::sub> being
-the name of the called subroutine. (Unless the subroutine is compiled
-in the package C<DB>.)
-
-=back
-
-Note that if C<&DB::sub> needs some external data to be setup for it
-to work, no subroutine call is possible until this is done. For the
-standard debugger C<$DB::deep> (how many levels of recursion deep into
-the debugger you can go before a mandatory break) gives an example of
-such a dependency.
-
-The minimal working debugger consists of one line
-
- sub DB::DB {}
-
-which is quite handy as contents of C<PERL5DB> environment
-variable:
-
- env "PERL5DB=sub DB::DB {}" perl -d your-script
-
-Another (a little bit more useful) minimal debugger can be created
-with the only line being
-
- sub DB::DB {print ++$i; scalar <STDIN>}
-
-This debugger would print the sequential number of encountered
-statement, and would wait for your C<CR> to continue.
-
-The following debugger is quite functional:
-
- {
- package DB;
- sub DB {}
- sub sub {print ++$i, " $sub\n"; &$sub}
- }
-
-It prints the sequential number of subroutine call and the name of the
-called subroutine. Note that C<&DB::sub> should be compiled into the
-package C<DB>.
-
-=head2 Debugger Internals
-
-At the start, the debugger reads your rc file (F<./.perldb> or
-F<~/.perldb> under Unix), which can set important options. This file may
-define a subroutine C<&afterinit> to be executed after the debugger is
-initialized.
-
-After the rc file is read, the debugger reads environment variable
-PERLDB_OPTS and parses it as a rest of C<O ...> line in debugger prompt.
-
-It also maintains magical internal variables, such as C<@DB::dbline>,
-C<%DB::dbline>, which are aliases for C<@{"::_<current_file"}>
-C<%{"::_<current_file"}>. Here C<current_file> is the currently
-selected (with the debugger's C<f> command, or by flow of execution)
-file.
-
-Some functions are provided to simplify customization. See L<"Debugger
-Customization"> for description of C<DB::parse_options(string)>. The
-function C<DB::dump_trace(skip[, count])> skips the specified number
-of frames, and returns a list containing info about the caller
-frames (all if C<count> is missing). Each entry is a hash with keys
-C<context> (C<$> or C<@>), C<sub> (subroutine name, or info about
-eval), C<args> (C<undef> or a reference to an array), C<file>, and
-C<line>.
-
-The function C<DB::print_trace(FH, skip[, count[, short]])> prints
-formatted info about caller frames. The last two functions may be
-convenient as arguments to C<E<lt>>, C<E<lt>E<lt>> commands.
-
-=head2 Other resources
-
-You did try the B<-w> switch, didn't you?
-
-=head2 BUGS
-
-You cannot get the stack frame information or otherwise debug functions
-that were not compiled by Perl, such as C or C++ extensions.
-
-If you alter your @_ arguments in a subroutine (such as with B<shift>
-or B<pop>, the stack backtrace will not show the original values.
-
-=head1 Debugging Perl memory usage
-
-Perl is I<very> frivolous with memory. There is a saying that to
-estimate memory usage of Perl, assume a reasonable algorithm of
-allocation, and multiply your estimates by 10. This is not absolutely
-true, but may give you a good grasp of what happens.
-
-Say, an integer cannot take less than 20 bytes of memory, a float
-cannot take less than 24 bytes, a string cannot take less than 32
-bytes (all these examples assume 32-bit architectures, the result are
-much worse on 64-bit architectures). If a variable is accessed in two
-of three different ways (which require an integer, a float, or a
-string), the memory footprint may increase by another 20 bytes. A
-sloppy malloc() implementation will make these numbers yet more.
-
-On the opposite end of the scale, a declaration like
-
- sub foo;
-
-may take (on some versions of perl) up to 500 bytes of memory.
-
-Off-the-cuff anecdotal estimates of a code bloat give a factor around
-8. This means that the compiled form of reasonable (commented
-indented etc.) code will take approximately 8 times more than the
-disk space the code takes.