X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=blobdiff_plain;f=pod%2Fperlhack.pod;h=cf38f0398041a7ef39d694115fcb5bc142d297a8;hb=8d159ec130d0a3a6340d8398c9db207a5efafc87;hp=73f485d086770050186e125157555c8790e49437;hpb=0503309d9983bed567ec4a7b90669b5b72f1273f;p=p5sagit%2Fp5-mst-13.2.git

diff --git a/pod/perlhack.pod b/pod/perlhack.pod
index 73f485d..cf38f03 100644
--- a/pod/perlhack.pod
+++ b/pod/perlhack.pod
@@ -760,8 +760,11 @@ This is very high-level code, enough to fit on a single screen, and it
 resembles the code found in L<perlembed>; most of the real action takes
 place in F<perl.c>
 
+F<perlmain.c> is generated by L<writemain> from F<miniperlmain.c> at
+make time, so you should make perl to follow this along.
+
 First, F<perlmain.c> allocates some memory and constructs a Perl
-interpreter:
+interpreter, along these lines:
 
     1 PERL_SYS_INIT3(&argc,&argv,&env);
     2
@@ -790,16 +793,19 @@ later: C<PerlMem_malloc> is either your system's C<malloc>, or Perl's
 own C<malloc> as defined in F<malloc.c> if you selected that option at
 configure time.
 
-Next, in line 7, we construct the interpreter; this sets up all the
-special variables that Perl needs, the stacks, and so on.
+Next, in line 7, we construct the interpreter using perl_construct, 
+also in F<perl.c>; this sets up all the special variables that Perl 
+needs, the stacks, and so on.
 
 Now we pass Perl the command line options, and tell it to go:
 
     exitstatus = perl_parse(my_perl, xs_init, argc, argv, (char **)NULL);
-    if (!exitstatus) {
-        exitstatus = perl_run(my_perl);
-    }
+    if (!exitstatus)
+        perl_run(my_perl);
+
+    exitstatus = perl_destruct(my_perl);
 
+    perl_free(my_perl);
 
 C<perl_parse> is actually a wrapper around C<S_parse_body>, as defined
 in F<perl.c>, which processes the command line options, sets up any
@@ -2221,7 +2227,7 @@ are expected to succeed (until they're specifically fixed, of course).
 =item minitest
 
 Run F<miniperl> on F<t/base>, F<t/comp>, F<t/cmd>, F<t/run>, F<t/io>,
-F<t/op>, and F<t/uni> tests.
+F<t/op>, F<t/uni> and F<t/mro> tests.
 
 =item test.valgrind check.valgrind utest.valgrind ucheck.valgrind
 
@@ -3112,10 +3118,10 @@ then finally report any memory problems.
 =head2 valgrind
 
 The excellent valgrind tool can be used to find out both memory leaks
-and illegal memory accesses.  As of August 2003 it unfortunately works
-only on x86 (ELF) Linux.  The special "test.valgrind" target can be used
-to run the tests under valgrind.  Found errors and memory leaks are
-logged in files named F<testfile.valgrind>.
+and illegal memory accesses.  As of version 3.3.0, Valgrind only
+supports Linux on x86, x86-64 and PowerPC.  The special "test.valgrind" 
+target can be used to run the tests under valgrind.  Found errors 
+and memory leaks are logged in files named F<testfile.valgrind>.
 
 Valgrind also provides a cachegrind tool, invoked on perl as: