Devel::NYTProf provides awesome timing information, and iirc it also can give you call graphs.
| [reply] |
Do you want to statically analyse a perl program without running it, and get a call graph for all possible flows of the program, or do you want to run the program normally under some sort of debug environment so that you get back a call graph for your test run?
As moritz said, if you run a perl program under a profiler, then then you should be able to get a call graph from your profiling tool. The problem is that you only learn about the run you have just done, and not about any exceptional circumstances that you can't simulate. Also if your legacy code has bit rotted to the point where it won't run at all, and you can't easily fix it into a runnable state, then profiling it won't help you.
Instead it is tempting to want to generate a call graph from static analysis of a perl program without running it. Unfortunately that is a lot harder, not least because (as you will frequency hear) Only perl can parse perl. The meaning of the saying is that only the perl binary (perl.exe) can reliably parse perl, and the only way it can do so is to run the perl program. You can attempt to write a separate parser for perl, but perl.exe is the only definitive perl parser, and the only one guaranteed to be correct. Additionally, if the perl program you are trying to analyse is broken or otherwise buggy, then it's meaning is undefined, so by definition there is no correct outcome to parsing it.
| [reply] |
thanks for your answers monks. NYTProf is a nice tool.
But still I agree with you what I need is a static analysis without actually running the code.
I tried B::Xref which caused segfaults only.
Since compiler backend seems to be the most promising idea aren't there any other tools around ?
| [reply] |
If there are bugs in B::Xref or any other modules, 1) upgrade 2) report bugs
| [reply] |
I created a static call graph generation script out of desperation, to untangle an undocumented part of a 30,000-line legacy script, in order to implement an urgent bug fix.
It reads the source code(s), uses GraphViz to generate a png, and then displays the image on-screen.
Since it uses simple line-by-line regexes, the formatting must be "sane" so that nesting can be determined (perltidy is useful here if the formatting is in bad shape).
Also, don't expect miracles such as parsing dynamic function calls, BEGIN blocks, etc.
The silver lining of a simple regex engine is that it can easily be extended for other languages.
The tool now supports awk, bash, basic, dart, fortran, go, lua, javascript, kotlin, matlab, pascal, perl, php, python, r, raku, ruby, rust, scala, swift, and tcl.
https://github.com/koknat/callGraph | [reply] |
