perl5db.pl

视频监控网络部分的协议ddns,的模块的实现代码,请大家大胆指正.

=head1 NAME 

perl5db.pl - the perl debugger

=head1 SYNOPSIS

    perl -d  your_Perl_script

=head1 DESCRIPTION

C<perl5db.pl> is the perl debugger. It is loaded automatically by Perl when
you invoke a script with C<perl -d>. This documentation tries to outline the
structure and services provided by C<perl5db.pl>, and to describe how you
can use them.

=head1 GENERAL NOTES

The debugger can look pretty forbidding to many Perl programmers. There are
a number of reasons for this, many stemming out of the debugger's history.

When the debugger was first written, Perl didn't have a lot of its nicer
features - no references, no lexical variables, no closures, no object-oriented
programming. So a lot of the things one would normally have done using such
features was done using global variables, globs and the C<local()> operator 
in creative ways.

Some of these have survived into the current debugger; a few of the more
interesting and still-useful idioms are noted in this section, along with notes
on the comments themselves.

=head2 Why not use more lexicals?

Experienced Perl programmers will note that the debugger code tends to use
mostly package globals rather than lexically-scoped variables. This is done
to allow a significant amount of control of the debugger from outside the
debugger itself.       

Unfortunately, though the variables are accessible, they're not well
documented, so it's generally been a decision that hasn't made a lot of
difference to most users. Where appropriate, comments have been added to
make variables more accessible and usable, with the understanding that these
I<are> debugger internals, and are therefore subject to change. Future
development should probably attempt to replace the globals with a well-defined
API, but for now, the variables are what we've got.

=head2 Automated variable stacking via C<local()>

As you may recall from reading C<perlfunc>, the C<local()> operator makes a 
temporary copy of a variable in the current scope. When the scope ends, the
old copy is restored. This is often used in the debugger to handle the 
automatic stacking of variables during recursive calls:

     sub foo {
        local $some_global++;

        # Do some stuff, then ...
        return;
     }

What happens is that on entry to the subroutine, C<$some_global> is localized,
then altered. When the subroutine returns, Perl automatically undoes the 
localization, restoring the previous value. Voila, automatic stack management.

The debugger uses this trick a I<lot>. Of particular note is C<DB::eval>, 
which lets the debugger get control inside of C<eval>'ed code. The debugger
localizes a saved copy of C<$@> inside the subroutine, which allows it to
keep C<$@> safe until it C<DB::eval> returns, at which point the previous
value of C<$@> is restored. This makes it simple (well, I<simpler>) to keep 
track of C<$@> inside C<eval>s which C<eval> other C<eval's>.

In any case, watch for this pattern. It occurs fairly often.

=head2 The C<^> trick

This is used to cleverly reverse the sense of a logical test depending on 
the value of an auxiliary variable. For instance, the debugger's C<S>
(search for subroutines by pattern) allows you to negate the pattern 
like this:

   # Find all non-'foo' subs:
   S !/foo/      

Boolean algebra states that the truth table for XOR looks like this:

=over 4

=item * 0 ^ 0 = 0 

(! not present and no match) --> false, don't print

=item * 0 ^ 1 = 1 

(! not present and matches) --> true, print

=item * 1 ^ 0 = 1 

(! present and no match) --> true, print

=item * 1 ^ 1 = 0 

(! present and matches) --> false, don't print

=back

As you can see, the first pair applies when C<!> isn't supplied, and
the second pair applies when it is. The XOR simply allows us to
compact a more complicated if-then-elseif-else into a more elegant 
(but perhaps overly clever) single test. After all, it needed this
explanation...

=head2 FLAGS, FLAGS, FLAGS

There is a certain C programming legacy in the debugger. Some variables,
such as C<$single>, C<$trace>, and C<$frame>, have I<magical> values composed
of 1, 2, 4, etc. (powers of 2) OR'ed together. This allows several pieces
of state to be stored independently in a single scalar. 

A test like

    if ($scalar & 4) ...

is checking to see if the appropriate bit is on. Since each bit can be 
"addressed" independently in this way, C<$scalar> is acting sort of like
an array of bits. Obviously, since the contents of C<$scalar> are just a 
bit-pattern, we can save and restore it easily (it will just look like
a number).

The problem, is of course, that this tends to leave magic numbers scattered
all over your program whenever a bit is set, cleared, or checked. So why do 
it?

=over 4

=item *

First, doing an arithmetical or bitwise operation on a scalar is
just about the fastest thing you can do in Perl: C<use constant> actually
creates a subroutine call, and array and hash lookups are much slower. Is
this over-optimization at the expense of readability? Possibly, but the 
debugger accesses these  variables a I<lot>. Any rewrite of the code will
probably have to benchmark alternate implementations and see which is the
best balance of readability and speed, and then document how it actually 
works.

=item *

Second, it's very easy to serialize a scalar number. This is done in 
the restart code; the debugger state variables are saved in C<%ENV> and then
restored when the debugger is restarted. Having them be just numbers makes
this trivial. 

=item *

Third, some of these variables are being shared with the Perl core 
smack in the middle of the interpreter's execution loop. It's much faster for 
a C program (like the interpreter) to check a bit in a scalar than to access 
several different variables (or a Perl array).

=back

=head2 What are those C<XXX> comments for?

Any comment containing C<XXX> means that the comment is either somewhat
speculative - it's not exactly clear what a given variable or chunk of 
code is doing, or that it is incomplete - the basics may be clear, but the
subtleties are not completely documented.

Send in a patch if you can clear up, fill out, or clarify an C<XXX>.

=head1 DATA STRUCTURES MAINTAINED BY CORE         

There are a number of special data structures provided to the debugger by
the Perl interpreter.

The array C<@{$main::{'_<'.$filename}}> (aliased locally to C<@dbline> via glob
assignment) contains the text from C<$filename>, with each element
corresponding to a single line of C<$filename>.

The hash C<%{'_<'.$filename}> (aliased locally to C<%dbline> via glob 
assignment) contains breakpoints and actions.  The keys are line numbers; 
you can set individual values, but not the whole hash. The Perl interpreter 
uses this hash to determine where breakpoints have been set. Any true value is
considered to be a breakpoint; C<perl5db.pl> uses C<$break_condition\0$action>.
Values are magical in numeric context: 1 if the line is breakable, 0 if not.

The scalar C<${"_<$filename"}> simply contains the string 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)>.

=head1 DEBUGGER STARTUP

When C<perl5db.pl> starts, it reads an rcfile (C<perl5db.ini> for
non-interactive sessions, C<.perldb> for interactive ones) that can set a number
of options. In addition, this file may define a subroutine C<&afterinit>
that will be executed (in the debugger's context) after the debugger has 
initialized itself.

Next, it checks the C<PERLDB_OPTS> environment variable and treats its 
contents as the argument of a C<o> command in the debugger.

=head2 STARTUP-ONLY OPTIONS

The following options can only be specified at startup.
To set them in your rcfile, add a call to
C<&parse_options("optionName=new_value")>.

=over 4

=item * TTY 

the TTY to use for debugging i/o.

=item * noTTY 

if set, goes in NonStop mode.  On interrupt, if TTY is not set,
uses the value of noTTY or F<$HOME/.perldbtty$$> to find TTY using
Term::Rendezvous.  Current variant is to have the name of TTY in this
file.

=item * ReadLine 

if false, a dummy ReadLine is used, so you can debug
ReadLine applications.

=item * NonStop 

if true, no i/o is performed until interrupt.

=item * LineInfo 

file or pipe to print line number info to.  If it is a
pipe, a short "emacs like" message is used.

=item * RemotePort 

host:port to connect to on remote host for remote debugging.

=item * HistFile

file to store session history to. There is no default and so no
history file is written unless this variable is explicitly set.

=item * HistSize

number of commands to store to the file specified in C<HistFile>.
Default is 100.

=back

=head3 SAMPLE RCFILE

 &parse_options("NonStop=1 LineInfo=db.out");
  sub afterinit { $trace = 1; }

The script will run without human intervention, putting trace
information into C<db.out>.  (If you interrupt it, you had better
reset C<LineInfo> to something I<interactive>!)

=head1 INTERNALS DESCRIPTION

=head2 DEBUGGER INTERFACE VARIABLES

Perl supplies the values for C<%sub>.  It effectively inserts
a C<&DB::DB();> in front of each place that can have a
breakpoint. At each subroutine call, it calls C<&DB::sub> with
C<$DB::sub> set to the called subroutine. It also inserts a C<BEGIN
{require 'perl5db.pl'}> before the first line.

After each C<require>d file is compiled, but before it is executed, a
call to C<&DB::postponed($main::{'_<'.$filename})> is done. C<$filename>
is the expanded name of the C<require>d file (as found via C<%INC>).

=head3 IMPORTANT INTERNAL VARIABLES

=head4 C<$CreateTTY>

Used to control when the debugger will attempt to acquire another TTY to be
used for input. 

=over   

=item * 1 -  on C<fork()>

=item * 2 - debugger is started inside debugger

=item * 4 -  on startup

=back

=head4 C<$doret>

The value -2 indicates that no return value should be printed.
Any other positive value causes C<DB::sub> to print return values.

=head4 C<$evalarg>

The item to be eval'ed by C<DB::eval>. Used to prevent messing with the current
contents of C<@_> when C<DB::eval> is called.

=head4 C<$frame>

Determines what messages (if any) will get printed when a subroutine (or eval)
is entered or exited. 

=over 4

=item * 0 -  No enter/exit messages

=item * 1 - Print I<entering> messages on subroutine entry

=item * 2 - Adds exit messages on subroutine exit. If no other flag is on, acts like 1+2.

=item * 4 - Extended messages: C<< <in|out> I<context>=I<fully-qualified sub name> from I<file>:I<line> >>. If no other flag is on, acts like 1+4.

=item * 8 - Adds parameter information to messages, and overloaded stringify and tied FETCH is enabled on the printed arguments. Ignored if C<4> is not on.

=item * 16 - Adds C<I<context> return from I<subname>: I<value>> messages on subroutine/eval exit. Ignored if C<4> is is not on.

=back

To get everything, use C<$frame=30> (or C<o f=30> as a debugger command).
The debugger internally juggles the value of C<$frame> during execution to
protect external modules that the debugger uses from getting traced.

=head4 C<$level>

Tracks current debugger nesting level. Used to figure out how many 
C<E<lt>E<gt>> pairs to surround the line number with when the debugger 
outputs a prompt. Also used to help determine if the program has finished
during command parsing.

=head4 C<$onetimeDump>

Controls what (if anything) C<DB::eval()> will print after evaluating an
expression.

=over 4

=item * C<undef> - don't print anything

=item * C<dump> - use C<dumpvar.pl> to display the value returned

=item * C<methods> - print the methods callable on the first item returned

=back

=head4 C<$onetimeDumpDepth>

Controls how far down C<dumpvar.pl> will go before printing C<...> while
dumping a structure. Numeric. If C<undef>, print all levels.

=head4 C<$signal>

Used to track whether or not an C<INT> signal has been detected. C<DB::DB()>,
which is called before every statement, checks this and puts the user into
command mode if it finds C<$signal> set to a true value.

=head4 C<$single>

Controls behavior during single-stepping. Stacked in C<@stack> on entry to
each subroutine; popped again at the end of each subroutine.

=over 4 

=item * 0 - run continuously.

=item * 1 - single-step, go into subs. The C<s> command.

=item * 2 - single-step, don't go into subs. The C<n> command.

=item * 4 - print current sub depth (turned on to force this when C<too much
recursion> occurs.

=back