I think haven't been doing a good job at explaining the problem. I am looking for a way to identify in a Perl program more precisely — generally more precise than a line and filename — where the program was at a "trace" point: which could be a call, place where an exception can occur, or a statement boundary.

If the runtime system kept line and column numbers associated with some of the opcodes passed from the parser, that would work. But realistically, this adds overhead and would be a fair bit of rewriting of the Perl interpreter. Another way to get more precise location information might be to rewrite the program to put each Perl token on a line. I doubt most people would be interested in such a solution, but a little more on this later.

Another solution would be to be able to get something like a program counter (PC) or opcode/opnode location and disassembly of some of the tree around that location.

There may be other possibilities as well. And if no solution comes up, I guess that's okay too.

Although perltidy might ameliorate the problem a little, to see why a program pretty-printer isn't going to always help (short of putting one token on a line), consider this code:

   ($a/$b, $c/$d);
[download]

If an "Illegal division by 0" occurs, was the division in the first entry of the array or the second?

Lastly, let me come back to what sounds like a crazy idea of putting one Perl token per line. In a Perl debugger I have been writing, there is a module for caching source-code lines and remapping locations in one file and line to another file and line. I don't have the front-end interface to that in yet like I do in some other debuggers. However with this, one could split the program up and then with this translation mechanism remap one position in the file with more lines back to a position in the original source text. But there would still need to be be some additional work to add in the column position though.

I'd likely first pursue the idea of dumping the opnodes for that line along with which opnode was active. See the likes of B::Terse or B::Concise for examples of dumping a tree of opnodes.

I'm not sure the best place to point you about the possibility of finding the currently active opnode in the call stack. Perhaps the guts of App::Stacktrace know how to answer that in one way.

- tye        

Count me in on liking to pursue that possibility too.

The challenges, as I understand it, are that currently B::Terse and B::Concise parse the source text a new rather than have the ability to work on an in place node structure. So the addresses might not be the same, even if the overall tree layout would be the same. Waving my hands, there might be a way to correlate the two sets of addresses used. But that bleeds into the other problem: being able to get at the equivalent of a PC and the opnodes of the tree that is currently live.

The aforementioned debugger currently does have a plugin to add a dissassemble command which attempts to allow you to see dissassembly of the code around where you are stopped if that's what you want.

However I have found that the B::Concise code may need improvement when using it more than once in a session with different format styles. Probably not a big issue since I don't think it a likely thing to do after initially settling on a dump style when new to B::Concise. But the frailty is there.

One line per token doesn't work, because line information seems only to be stored in the COP node. A COP seems to be emitted only on statement boundaries. But see also Re^4: How can I get the current OP address (akin to PC)?