The goal is to profile Inline'd C code. The method suggested here was to build the module into a statically-linked perl with the -pg flag on compile and link, so as to allow gprof the requisite visibility. This means compiling / linking the module code with -pg, and then linking a perl with -pg.
For the module, the following suffices: Add CCFLAGS => '-pg', LDDLFLAGS => '-pg -other_options_required' to the "use Inline => Config ..." part of the module code. The '-other_options_required' is necessary because the LDDLFLAGS actually replaces the regular LDDLFLAGS and your module probably won't compile without those. Find them by running a normal make and noting the linking options. For example, mine are '-shared -L/usr/local/lib', so my config is LDDLFLAGS => '-pg -shared -L/usr/local/lib'. (You may also have to edit your local Config.pm if you have an 'optimize' item that conflicts with -pg.) Then we indicate we want a static build by passing LINKTYPE=static to Makefile.PL when making the module: perl Makefile.PL LINKTYPE=static make Now make a static perl: make perl You will now have a perl executable in the current directory, BUT it is inadequate because the -pg option was not present during linking. What we do is edit the Makefile.aperl which was generated, and make it again by hand. There is probably a proper place to put things but what I did was just add -pg to the end of the CC item, since I want it there whensoever my gcc is called. Now call by hand: make -f Makefile.aperl perl And there we are, a proper statically-linked perl. Calling some program with this perl, eg ./perl -Mblib bin/benchmark ... gives us the gmon.out file as was hoped for. Unfortunately none of the Inline'd functions are to be found profiled when I execute 'gprof ./perl gmon.out'. Instead there is an exhaustive list of the 160 internal Perl_* functions used during the benchmark program. MACOSX On Macosx, the procedure is a little different. When editing the Makefile.aperl, I have to change 'libperl.a' to 'libperl.dylib' (no libperl.a is provided on osx, even with the developer tools installed). The results also differ. Instead of only internal functions, gprof presents the only two Inline'd functions called by the interpreter, and ONLY those. Plus they are recorded as having zero runtime, when I know they account for the bulk of runtime. I would really like to have ALL of the internally- or externally-called functions in the module profiled. The upshot of it is, there are still problems, but we're definitely well on the way. Any suggestions very welcome! ----------------------------------------------------------------------------------- ATTENTION: DO NOT read, copy or disseminate this communication unless you are the intended addressee. This message and any file(s) or attachment(s) transmitted with it are confidential, intended only for the named recipient, and may contain information that is a trade secret, proprietary, protected by the attorney work product doctrine, subject to the attorney-client privilege, or is otherwise protected against unauthorized use or disclosure. This message and any file(s) or attachment(s) transmitted with it are transmitted based on a reasonable expectation of privacy consistent with ABA Formal Opinion No. 99-413. If you have received this communication in error, please e-mail the sender and notify the sender immediately that you have received the communication in error. Thank you.
