http://www.perlmonks.org?node_id=466944


in reply to Becoming familiar with a too-big codebase?

To figure out what programs are doing, I used B::Xref and some wrapper scripts to generate a call tree for code written in a procedural manner.

You might developing something along those lines yourself (since I foolishly wrote my program at work, it is,of course, copyright by my company, so I can't post code for you).

Learn to use the perl debugger: it's handy. It will let you execute arbitrary perl code to see what it does, single step through functions, stop at certain lines, and so forth. While you just can't "go back" to a previously executed line in the debugger, you can often just copy the line, and single step through it. This is most useful for function calls that have gone awry.

eg. Suppose the line $x = foo($y) returns the wrong thing. Just type s foo($y) into the debugger, and single step through foo() until you find the call in foo() that's wrong, say bar(). Then single step through bar(), and so on. Keep chasing your way down the call stack until you find the bug.

The debugger certainly doesn't default to printing each subroutine that's called, but it can be made to do it by writing some custom debugging code. There may be CPAN modules that will do this for you, as well.

Do a 'perldoc perldebug' for the standard debugger documentation; do 'perldoc perldebguts' to learn how to reprogram the internals of the perl debugger to make it do other useful things.
--
Ytrew Q. Uiop