Change 33570 by [EMAIL PROTECTED] on 2008/03/26 11:17:38
Subject: Re: [PATCH] perlhack.pod update walkthrough
From: "Leon Brocard" <[EMAIL PROTECTED]>
Date: Wed, 26 Mar 2008 10:53:43 +0000
Message-ID: <[EMAIL PROTECTED]>
Affected files ...
... //depot/perl/pod/perlhack.pod#138 edit
Differences ...
==== //depot/perl/pod/perlhack.pod#138 (text) ====
Index: perl/pod/perlhack.pod
--- perl/pod/perlhack.pod#137~32616~ 2007-12-12 05:28:23.000000000 -0800
+++ perl/pod/perlhack.pod 2008-03-26 04:17:38.000000000 -0700
@@ -760,8 +760,11 @@
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 @@
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
@@ -3112,10 +3118,10 @@
=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:
End of Patch.
