Tweaks and reflowing for the cc/linker split.

[p5sagit/p5-mst-13.2.git] / pod / perlhack.pod

diff --git a/pod/perlhack.pod b/pod/perlhack.pod
index 7e51c3b..cf38f03 100644 (file)
--- 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
@@ -888,7 +894,7 @@ retrieves the return op from it, and returns it.
 
 =item Exception handing
 
-Perl's exception handing (i.e. C<die> etc) is built on top of the low-level
+Perl's exception handing (i.e. C<die> etc.) is built on top of the low-level
 C<setjmp()>/C<longjmp()> C-library functions. These basically provide a
 way to capture the current PC and SP registers and later restore them; i.e.
 a C<longjmp()> continues at the point in code where a previous C<setjmp()>
@@ -1556,7 +1562,7 @@ C<-Wdeclaration-after-statement>
 =back
 
 The following flags would be nice to have but they would first need
-their own Stygian stablemaster:
+their own Augean stablemaster:
 
 =over 4
 
@@ -2111,6 +2117,11 @@ The old home for the module tests, you shouldn't put anything new in
 here.  There are still some bits and pieces hanging around in here
 that need to be moved.  Perhaps you could move them?  Thanks!
 
+=item F<t/mro/>
+
+Tests for perl's method resolution order implementations
+(see L<mro>).
+
 =item F<t/op/>
 
 Tests for perl's built in functions that don't fit into any of the
@@ -2216,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
 
@@ -3107,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: