in reply to Re^2: Identifying a location with finer granularity than a line number
in thread Identifying a location with finer granularity than a line number

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        

  • Comment on Re^3: Identifying a location with finer granularity than a line number (-MO=)

Replies are listed 'Best First'.
Re^4: Identifying a location with finer granularity than a line number (-MO=)
by rockyb (Scribe) on Aug 15, 2012 at 04:27 UTC

    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.

[reply]
      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

      I'm pretty sure you are precisely wrong on that point.

      The B::Concise man page shows how to call the compile() method which does not take Perl source code (despite what the name "compile" might imply) but only a list of subroutine names or CODE refs. So it seems pretty clear that the module walks the opnode tree of your existing interpreter instance for Perl code that you have already compiled. Looking at the source code of B::Concise and B confirms this.

      - tye        

[reply]

        Ah, yes. Ok. So now how can I get a CODE ref from the call stack of a running Perl program?

        Independent of this particular problem, it's something I'd want to be able to do. I can't remember the details now but I recall needing a CODE ref (as opposed to a in "context") in conjunction with the module Scope::Upper

[reply]
      Your on the right idea, you will have to show the opcode disassembly if you want better resolution than a line number.
[reply]

In Section Seekers of Perl Wisdom