core'' means you're changing the C source code to the Perl
interpreter. ``A core module'' is one that ships with Perl.
+=head2 Keeping in sync
+
The source code to the Perl interpreter, in its different versions, is
kept in a repository managed by a revision control system (which is
currently the Perforce program, see http://perforce.com/). The
ftp://ftp.linux.activestate.com/pub/staff/gsar/APC/
-Selective parts are also visible via the rsync protocol. To get all
-the individual changes to the mainline since the last development
-release, use the following command:
-
- rsync -avuz rsync://ftp.linux.activestate.com/perl-diffs perl-diffs
-
-Use this to get the latest source tree in full:
-
- rsync -avuz rsync://ftp.linux.activestate.com/perl-current perl-current
+If you are a member of the perl5-porters mailing list, it is a good
+thing to keep in touch with the most recent changes. If not only to
+verify if what you would have posted as a bug report isn't already
+solved in the most recent available perl development branch, also
+known as perl-current, bleading edge perl, bleedperl or bleadperl.
Needless to say, the source code in perl-current is usually in a perpetual
state of evolution. You should expect it to be very buggy. Do B<not> use
it for any purpose other than testing and development.
+Keeping in sync with the most recent branch can be done in several ways,
+but the most convenient and reliable way is using B<rsync>, available at
+ftp://rsync.samba.org/pub/rsync/ . (You can also get the most recent
+branch by FTP.)
+
+If you choose to keep in sync using rsync, there are two approaches
+to doing so:
+
+=over 4
+
+=item rsync'ing the source tree
+
+Presuming you are in the directory where your perl source resides
+and you have rsync installed and available, you can `upgrade' to
+the bleadperl using:
+
+ # rsync -avz rsync://ftp.linux.activestate.com/perl-current/ .
+
+This takes care of updating every single item in the source tree to
+the latest applied patch level, creating files that are new (to your
+distribution) and setting date/time stamps of existing files to
+reflect the bleadperl status.
+
+Note that this will not delete any files that were in '.' before
+the rsync. Once you are sure that the rsync is running correctly,
+run it with the --delete and the --dry-run options like this:
+
+ # rsync -avz --delete --dry-run rsync://ftp.linux.activestate.com/perl-current/ .
+
+This will I<simulate> an rsync run that also deletes files not
+present in the bleadperl master copy. Observe the results from
+this run closely. If you are sure that the actual run would delete
+no files precious to you, you could remove the '--dry-run' option.
+
+You can than check what patch was the latest that was applied by
+looking in the file B<.patch>, which will show the number of the
+latest patch.
+
+If you have more than one machine to keep in sync, and not all of
+them have access to the WAN (so you are not able to rsync all the
+source trees to the real source), there are some ways to get around
+this problem.
+
+=over 4
+
+=item Using rsync over the LAN
+
+Set up a local rsync server which makes the rsynced source tree
+available to the LAN and sync the other machines against this
+directory.
+
+From http://rsync.samba.org/README.html:
+
+ "Rsync uses rsh or ssh for communication. It does not need to be
+ setuid and requires no special privileges for installation. It
+ does not require an inetd entry or a daemon. You must, however,
+ have a working rsh or ssh system. Using ssh is recommended for
+ its security features."
+
+=item Using pushing over the NFS
+
+Having the other systems mounted over the NFS, you can take an
+active pushing approach by checking the just updated tree against
+the other not-yet synced trees. An example would be
+
+ #!/usr/bin/perl -w
+
+ use strict;
+ use File::Copy;
+
+ my %MF = map {
+ m/(\S+)/;
+ $1 => [ (stat $1)[2, 7, 9] ]; # mode, size, mtime
+ } `cat MANIFEST`;
+
+ my %remote = map { $_ => "/$_/pro/3gl/CPAN/perl-5.7.1" } qw(host1 host2);
+
+ foreach my $host (keys %remote) {
+ unless (-d $remote{$host}) {
+ print STDERR "Cannot Xsync for host $host\n";
+ next;
+ }
+ foreach my $file (keys %MF) {
+ my $rfile = "$remote{$host}/$file";
+ my ($mode, $size, $mtime) = (stat $rfile)[2, 7, 9];
+ defined $size or ($mode, $size, $mtime) = (0, 0, 0);
+ $size == $MF{$file}[1] && $mtime == $MF{$file}[2] and next;
+ printf "%4s %-34s %8d %9d %8d %9d\n",
+ $host, $file, $MF{$file}[1], $MF{$file}[2], $size, $mtime;
+ unlink $rfile;
+ copy ($file, $rfile);
+ utime time, $MF{$file}[2], $rfile;
+ chmod $MF{$file}[0], $rfile;
+ }
+ }
+
+though this is not perfect. It could be improved with checking
+file checksums before updating. Not all NFS systems support
+reliable utime support (when used over the NFS).
+
+=back
+
+=item rsync'ing the patches
+
+The source tree is maintained by the pumpking who applies patches to
+the files in the tree. These patches are either created by the
+pumpking himself using C<diff -c> after updating the file manually or
+by applying patches sent in by posters on the perl5-porters list.
+These patches are also saved and rsync'able, so you can apply them
+yourself to the source files.
+
+Presuming you are in a directory where your patches reside, you can
+get them in sync with
+
+ # rsync -avz rsync://ftp.linux.activestate.com/perl-current-diffs/ .
+
+This makes sure the latest available patch is downloaded to your
+patch directory.
+
+It's then up to you to apply these patches, using something like
+
+ # last=`ls -rt1 *.gz | tail -1`
+ # rsync -avz rsync://ftp.linux.activestate.com/perl-current-diffs/ .
+ # find . -name '*.gz' -newer $last -exec gzcat {} \; >blead.patch
+ # cd ../perl-current
+ # patch -p1 -N <../perl-current-diffs/blead.patch
+
+or, since this is only a hint towards how it works, use CPAN-patchaperl
+from Andreas König to have better control over the patching process.
+
+=back
+
+=head3 Why rsync the source tree
+
+=over 4
+
+=item It's easier
+
+Since you don't have to apply the patches yourself, you are sure all
+files in the source tree are in the right state.
+
+=item It's more recent
+
+According to Gurusamy Sarathy:
+
+ "... The rsync mirror is automatic and syncs with the repository
+ every five minutes.
+
+ "Updating the patch area still requires manual intervention
+ (with all the goofiness that implies, which you've noted) and
+ is typically on a daily cycle. Making this process automatic
+ is on my tuit list, but don't ask me when."
+
+=item It's more reliable
+
+Well, since the patches are updated by hand, I don't have to say any
+more ... (see Sarathy's remark).
+
+=back
+
+=head3 Why rsync the patches
+
+=over 4
+
+=item It's easier
+
+If you have more than one machine that you want to keep in track with
+bleadperl, it's easier to rsync the patches only once and then apply
+them to all the source trees on the different machines.
+
+In case you try to keep in pace on 5 different machines, for which
+only one of them has access to the WAN, rsync'ing all the source
+trees should than be done 5 times over the NFS. Having
+rsync'ed the patches only once, I can apply them to all the source
+trees automatically. Need you say more ;-)
+
+=item It's a good reference
+
+If you do not only like to have the most recent development branch,
+but also like to B<fix> bugs, or extend features, you want to dive
+into the sources. If you are a seasoned perl core diver, you don't
+need no manuals, tips, roadmaps, perlguts.pod or other aids to find
+your way around. But if you are a starter, the patches may help you
+in finding where you should start and how to change the bits that
+bug you.
+
+The file B<Changes> is updated on occasions the pumpking sees as his
+own little sync points. On those occasions, he releases a tar-ball of
+the current source tree (i.e. perl@7582.tar.gz), which will be an
+excellent point to start with when choosing to use the 'rsync the
+patches' scheme. Starting with perl@7582, which means a set of source
+files on which the latest applied patch is number 7582, you apply all
+succeeding patches available from then on (7583, 7584, ...).
+
+You can use the patches later as a kind of search archive.
+
+=over 4
+
+=item Finding a start point
+
+If you want to fix/change the behaviour of function/feature Foo, just
+scan the patches for patches that mention Foo either in the subject,
+the comments, or the body of the fix. A good chance the patch shows
+you the files that are affected by that patch which are very likely
+to be the starting point of your journey into the guts of perl.
+
+=item Finding how to fix a bug
+
+If you've found I<where> the function/feature Foo misbehaves, but you
+don't know how to fix it (but you do know the change you want to
+make), you can, again, peruse the patches for similar changes and
+look how others apply the fix.
+
+=item Finding the source of misbehaviour
+
+When you keep in sync with bleadperl, the pumpking would love to
+I<see> that the community efforts really work. So after each of his
+sync points, you are to 'make test' to check if everything is still
+in working order. If it is, you do 'make ok', which will send an OK
+report to perlbug@perl.org. (If you do not have access to a mailer
+from the system you just finished successfully 'make test', you can
+do 'make okfile', which creates the file C<perl.ok>, which you can
+than take to your favourite mailer and mail yourself).
+
+But of course, as always, things will not always lead to a success
+path, and one or more test do not pass the 'make test'. Before
+sending in a bug report (using 'make nok' or 'make nokfile'), check
+the mailing list if someone else has reported the bug already and if
+so, confirm it by replying to that message. If not, you might want to
+trace the source of that misbehaviour B<before> sending in the bug,
+which will help all the other porters in finding the solution.
+
+Here the saved patches come in very handy. You can check the list of
+patches to see which patch changed what file and what change caused
+the misbehaviour. If you note that in the bug report, it saves the
+one trying to solve it, looking for that point.
+
+=back
+
+If searching the patches is too bothersome, you might consider using
+perl's bugtron to find more information about discussions and
+ramblings on posted bugs.
+
+=back
+
+If you want to get the best of both worlds, rsync both the source
+tree for convenience, reliability and ease and rsync the patches
+for reference.
+
+=head2 Submitting patches
+
Always submit patches to I<perl5-porters@perl.org>. This lets other
porters review your patch, which catches a surprising number of errors
in patches. Either use the diff program (available in source code
To report a bug in Perl, use the program I<perlbug> which comes with
Perl (if you can't get Perl to work, send mail to the address
-I<perlbug@perl.com> or I<perlbug@perl.org>). Reporting bugs through
+I<perlbug@perl.org> or I<perlbug@perl.com>). Reporting bugs through
I<perlbug> feeds into the automated bug-tracking system, access to
which is provided through the web at I<http://bugs.perl.org/>. It
often pays to check the archives of the perl5-porters mailing list to
macro to force a PV. As a side effect, C<tlen> gets set to the current
value of the PV, and the PV itself is returned to C<junk>.
-In line 7, we make sure that the SV will have enough room to accomodate
+In line 7, we make sure that the SV will have enough room to accommodate
the old string, the new string and the null terminator. If C<LEN> isn't
big enough, C<SvGROW> will reallocate space for us.
7 call_method("PUSH", G_SCALAR|G_DISCARD);
8 LEAVE;
9 POPSTACK;
-
+
The lines which concern the mark stack are the first, fifth and last
lines: they save away, restore and remove the current position of the
argument stack.
1 PP(pp_add)
2 {
- 3 djSP; dATARGET; tryAMAGICbin(add,opASSIGN);
+ 3 dSP; dATARGET; tryAMAGICbin(add,opASSIGN);
4 {
5 dPOPTOPnnrl_ul;
6 SETn( left + right );
Some of the functionality of the debugging code can be achieved using XS
modules.
-
+
-Dr => use re 'debug'
-Dx => use O 'Debug'
=item break source.c:xxx
Tells the debugger that we'll want to pause execution when we reach
-either the named function (but see L</Function names>!) or the given
+either the named function (but see L<perlguts/Internal Functions>!) or the given
line in the named source file.
=item step
Run until the end of the current function, then stop again.
-=item
+=item 'enter'
Just pressing Enter will do the most recent operation again - it's a
blessing when stepping through miles of source code.
(gdb) break Perl_pp_add
Breakpoint 1 at 0x46249f: file pp_hot.c, line 309.
-Notice we use C<Perl_pp_add> and not C<pp_add> - see L<perlguts/Function Names>.
+Notice we use C<Perl_pp_add> and not C<pp_add> - see L<perlguts/Internal Functions>.
With the breakpoint in place, we can run our program:
(gdb) run -e '$b = "6XXXX"; $c = 2.3; $a = $b + $c'
libraries, and then:
Breakpoint 1, Perl_pp_add () at pp_hot.c:309
- 309 djSP; dATARGET; tryAMAGICbin(add,opASSIGN);
+ 309 dSP; dATARGET; tryAMAGICbin(add,opASSIGN);
(gdb) step
311 dPOPTOPnnrl_ul;
(gdb)
sprintf "%vd", pack("C0U*",1,20,300,4000);
print "ok $test\n"; $test++;
-Musn't forget to change the number of tests which appears at the top, or
+Mustn't forget to change the number of tests which appears at the top, or
else the automated tester will get confused:
-print "1..156\n";
All done. Now let's create the patch. F<Porting/patching.pod> tells us
that if we're making major changes, we should copy the entire directory
to somewhere safe before we begin fiddling, and then do
-
+
diff -ruN old new > patch
However, we know which files we've changed, and we can simply do this:
And finally, we submit it, with our rationale, to perl5-porters. Job
done!
+=head1 EXTERNAL TOOLS FOR DEBUGGING PERL
+
+Sometimes it helps to use external tools while debugging and
+testing Perl. This section tries to guide you through using
+some common testing and debugging tools with Perl. This is
+meant as a guide to interfacing these tools with Perl, not
+as any kind of guide to the use of the tools themselves.
+
+=head2 Rational Software's Purify
+
+Purify is a commercial tool that is helpful in identifying
+memory overruns, wild pointers, memory leaks and other such
+badness. Perl must be compiled in a specific way for
+optimal testing with Purify. Purify is available under
+Windows NT, Solaris, HP-UX, SGI, and Siemens Unix.
+
+The only currently known leaks happen when there are
+compile-time errors within eval or require. (Fixing these
+is non-trivial, unfortunately, but they must be fixed
+eventually.)
+
+=head2 Purify on Unix
+
+On Unix, Purify creates a new Perl binary. To get the most
+benefit out of Purify, you should create the perl to Purify
+using:
+
+ sh Configure -Accflags=-DPURIFY -Doptimize='-g' \
+ -Uusemymalloc -Dusemultiplicity
+
+where these arguments mean:
+
+=over 4
+
+=item -Accflags=-DPURIFY
+
+Disables Perl's arena memory allocation functions, as well as
+forcing use of memory allocation functions derived from the
+system malloc.
+
+=item -Doptimize='-g'
+
+Adds debugging information so that you see the exact source
+statements where the problem occurs. Without this flag, all
+you will see is the source filename of where the error occurred.
+
+=item -Uusemymalloc
+
+Disable Perl's malloc so that Purify can more closely monitor
+allocations and leaks. Using Perl's malloc will make Purify
+report most leaks in the "potential" leaks category.
+
+=item -Dusemultiplicity
+
+Enabling the multiplicity option allows perl to clean up
+thoroughly when the interpreter shuts down, which reduces the
+number of bogus leak reports from Purify.
+
+=back
+
+Once you've compiled a perl suitable for Purify'ing, then you
+can just:
+
+ make pureperl
+
+which creates a binary named 'pureperl' that has been Purify'ed.
+This binary is used in place of the standard 'perl' binary
+when you want to debug Perl memory problems.
+
+As an example, to show any memory leaks produced during the
+standard Perl testset you would create and run the Purify'ed
+perl as:
+
+ make pureperl
+ cd t
+ ../pureperl -I../lib harness
+
+which would run Perl on test.pl and report any memory problems.
+
+Purify outputs messages in "Viewer" windows by default. If
+you don't have a windowing environment or if you simply
+want the Purify output to unobtrusively go to a log file
+instead of to the interactive window, use these following
+options to output to the log file "perl.log":
+
+ setenv PURIFYOPTIONS "-chain-length=25 -windows=no \
+ -log-file=perl.log -append-logfile=yes"
+
+If you plan to use the "Viewer" windows, then you only need this option:
+
+ setenv PURIFYOPTIONS "-chain-length=25"
+
+=head2 Purify on NT
+
+Purify on Windows NT instruments the Perl binary 'perl.exe'
+on the fly. There are several options in the makefile you
+should change to get the most use out of Purify:
+
+=over 4
+
+=item DEFINES
+
+You should add -DPURIFY to the DEFINES line so the DEFINES
+line looks something like:
+
+ DEFINES = -DWIN32 -D_CONSOLE -DNO_STRICT $(CRYPT_FLAG) -DPURIFY=1
+
+to disable Perl's arena memory allocation functions, as
+well as to force use of memory allocation functions derived
+from the system malloc.
+
+=item USE_MULTI = define
+
+Enabling the multiplicity option allows perl to clean up
+thoroughly when the interpreter shuts down, which reduces the
+number of bogus leak reports from Purify.
+
+=item #PERL_MALLOC = define
+
+Disable Perl's malloc so that Purify can more closely monitor
+allocations and leaks. Using Perl's malloc will make Purify
+report most leaks in the "potential" leaks category.
+
+=item CFG = Debug
+
+Adds debugging information so that you see the exact source
+statements where the problem occurs. Without this flag, all
+you will see is the source filename of where the error occurred.
+
+=back
+
+As an example, to show any memory leaks produced during the
+standard Perl testset you would create and run Purify as:
+
+ cd win32
+ make
+ cd ../t
+ purify ../perl -I../lib harness
+
+which would instrument Perl in memory, run Perl on test.pl,
+then finally report any memory problems.
+
+=head2 Compaq's/Digital's Third Degree
+
+Third Degree is a tool for memory leak detection and memory access checks.
+It is one of the many tools in the ATOM toolkit. The toolkit is only
+available on Tru64 (formerly known as Digital UNIX formerly known as
+DEC OSF/1).
+
+When building Perl, you must first run Configure with -Doptimize=-g
+and -Uusemymalloc flags, after that you can use the make targets
+"perl.third" and "test.third".
+
+The short story is that with "atom" you can instrument the Perl
+executable to create a new executable called F<perl.third>. When the
+instrumented executable is run, it creates a log of dubious memory
+traffic in file called F<perl.3log>. See the manual pages of atom and
+third for more information. The most extensive Third Degree
+documentation is available in the Compaq "Tru64 UNIX Programmer's
+Guide", chapter "Debugging Programs with Third Degree".
+
+The "test.third" leaves a lot of files named F<perl.3log.*> in the t/
+subdirectory. There is a problem with these files: Third Degree is so
+effective that it finds problems also in the system libraries.
+Therefore there are certain types of errors that you should ignore in
+your debugging. Errors with stack traces matching
+
+ __actual_atof|__catgets|_doprnt|__exc_|__exec|_findio|__localtime|setlocale|__sia_|__strxfrm
+
+(all in libc.so) are known to be non-serious. You can also
+ignore the combinations
+
+ Perl_gv_fetchfile() calling strcpy()
+ S_doopen_pmc() calling strcmp()
+
+causing "rih" (reading invalid heap) errors.
+
+There are also leaks that for given certain definition of a leak,
+aren't. See L</PERL_DESTRUCT_LEVEL> for more information.
+
+=head2 PERL_DESTRUCT_LEVEL
+
+If you want to run any of the tests yourself manually using the
+pureperl or perl.third executables, please note that by default
+perl B<does not> explicitly cleanup all the memory it has allocated
+(such as global memory arenas) but instead lets the exit() of
+the whole program "take care" of such allocations, also known
+as "global destruction of objects".
+
+There is a way to tell perl to do complete cleanup: set the
+environment variable PERL_DESTRUCT_LEVEL to a non-zero value.
+The t/TEST wrapper does set this to 2, and this is what you
+need to do too, if you don't want to see the "global leaks":
+
+ PERL_DESTRUCT_LEVEL=2 ./perl.third t/foo/bar.t
+
+=head2 Gprof Profiling
+
+gprof is a profiling tool available in many UNIX platforms.
+The profiling is based on statistical time-sampling; this means that
+some routines, especially those executing really fast, may be missed.
+
+You can build a profiled version of perl called "perl.gprof" by
+invoking the make target "perl.gprof". Running the profiled version
+of Perl will create an output file called F<gmon.out> is created which
+contains the profiling data collected during the execution.
+
+The gprof tool can then display the collected data in various ways.
+Usually gprof understands the following options:
+
+=over 4
+
+=item -a
+
+Suppress statically defined functions from the profile.
+
+=item -b
+
+Suppress the verbose descriptions in the profile.
+
+=item -e routine
+
+Exclude the given routine and its descendants from the profile.
+
+=item -f routine
+
+Display only the given routine and its descendants in the profile.
+
+=item -s
+
+Generate a summary file called F<gmon.sum> which then may be given
+to subsequent gprof runs to accumulate data over several runs.
+
+=item -z
+
+Display routines that have zero usage.
+
+=back
+
+For more detailed explanation of the available commands and output
+formats, see your own local documentation of gprof.
+
+=head2 Pixie Profiling
+
+Pixie is a profiling tool available on IRIX and Tru64
+(aka Digital UNIX aka DEC OSF/1) platforms. Pixie does its profiling
+using "basic-block counting". A basic block is a program region that
+is entered only at the beginning and exited only at the end.
+
+You can build a profiled version of perl called F<perl.pixie> by
+invoking the make target "perl.pixie" (in Tru64 a file called
+F<perl.Addrs> will also be silently created, this file contains the
+addresses of the basic blocks). Running the profiled version of Perl
+will create a new file called "perl.Counts" which contains the counts
+for the basic block for that particular program execution.
+
+To display the results you must use the "prof" utility. The exact
+incantation depends on your operating system, "prof perl.Counts" in
+IRIX, and "prof -pixie -all -L. perl" in Tru64.
+
+In IRIX the following prof options are available:
+
+=over 4
+
+=item -h
+
+Reports the most heavily used lines in descending order of use.
+Useful for finding the hotspot lines.
+
+=item -l
+
+Groups lines by procedure, with procedures sorted in descending order of use.
+Within a procedure, lines are listed in source order.
+Useful for finding the hotspots of procedures.
+
+=back
+
+In Tru64 the following options are available:
+
+=over 4
+
+=item -p[rocedures]
+
+Procedures sorted in descending order by the number of cycles executed
+in each procedure. Useful for finding the hotspot procedures.
+(This is the default option.)
+
+=item -h[eavy]
+
+Lines sorted in descending order by the number of cycles executed in
+each line. Useful for finding the hotspot lines.
+
+=item -i[nvocations]
+
+The called procedures are sorted in descending order by number of calls
+made to the procedures. Useful for finding the most used procedures.
+
+=item -l[ines]
+
+Grouped by procedure, sorted by cycles executed per procedure.
+Useful for finding the hotspots of procedures.
+
+=item -testcoverage
+
+The compiler emitted code for these lines, but the code was unexecuted.
+
+=item -z[ero]
+
+Unexecuted procedures.
+
+=back
+
+For further information, see your system's manual pages for pixie and prof.
+
=head2 CONCLUSION
We've had a brief look around the Perl source, an overview of the stages
F<perl> goes through when it's running your code, and how to use a
-debugger to poke at the Perl guts. Finally, we took a very simple
-problem and demonstrated how to solve it fully - with documentation,
-regression tests, and finally a patch for submission to p5p.
+debugger to poke at the Perl guts. We took a very simple problem and
+demonstrated how to solve it fully - with documentation, regression
+tests, and finally a patch for submission to p5p. Finally, we talked
+about how to use external tools to debug and test Perl.
I'd now suggest you read over those references again, and then, as soon
as possible, get your hands dirty. The best way to learn is by doing,
=item *
+Do read the README associated with your operating system, e.g. README.aix
+on the IBM AIX OS. Don't hesitate to supply patches to that README if
+you find anything missing or changed over a new OS release.
+
+=item *
+
Find an area of Perl that seems interesting to you, and see if you can
work out how it works. Scan through the source, and step over it in the
debugger. Play, poke, investigate, fiddle! You'll probably get to
https://perl5.git.perl.org / perl5.git / blobdiff