Instrumenting Parrot

Progress this week was not bad. To recap, here’s what I got done this week:

1. Handle exit/unhandled exceptions.Whenever the exit opcode is found, Parrot will throw a CONTROL_EXIT exception which will propogate up the exception handler stack to the first exception handler which can handle it. In most cases, this will be the C exception handler created before entering the runloop in the function runops (see src/call/ops.c), and trigger the interpreter cleanup routines. Exiting in this manner will not allow the instruments to be finalized. So by inserting another C exception handler after this point, such exceptions can be caught and the runloop can exit normally, allowing the instruments to be finalized. As a plus point, since C handlers act as a catchall for exceptions, any unhandled exceptions will also be caught, again, allowing the instruments to be finalized.To this end, I also modified the Parrot_runloop struct (see include/parrot/call.h) and the appropriate routines to have a reference to the thrown exception, allowing the C exception handler to know what was thrown.
2. Cleanup the hook tables on destroyThis was listed as todo in the source, so I did it by first creating a new function to delete a list and then calling that function for each hook list.
3. Update the op callback interface.Previously, on calling the callback, 3 parameters were passed. The parameters were, the current relative PC (Program Counter), a ResizablePMCArray containing the op number and its arguments, and the Instrument object itself. This wasn’t very convenient, as to get the information about the op, one has to get the OpLib instance and then obtain the OpCode instance for the op in question.So I reworked it instead, creating an InstrumentOp dynpmc which conveniently allows looking up most of the information required from it, along with the file, line and namespace the op is in (accuracy of this is subject to the core’s ability to obtain the info). Getting the file, line and namespace wasn’t particularly hard. With the initial guidance from cotto, I managed to trace it all the way to Parrot_Context_get_info (see src/sub.c), which conveniently is already marked PARROT_EXPORT and provides the information I wanted in the form of the Parrot_Context_info struct.

   Additionally, in the process of fleshing out the InstrumentOp dynpmc, I also removed a todo item with regards to the special ops which have variable arguments (set_args_pc, get_results_pc, get_params_pc, set_returns_pc), which up until then, were simply ignored.

4. Hooks on dynops.This was listed as todo in runtime/parrot/library/Instrument/Probe.nqp previously. In the process of designing tests for the class Instrument::Probe, I got sidetracked into revisiting this todo. Now, upon detection of any dynop libraries, all probes that have pending op hooks are disabled and reenabled, and in the process attaching hooks to the relevant dynop if found. The tests for Probe.nqp and EventLibrary.nqp are still pending, as I’m looking at whether I can improve on the Instrument::Probe and Instrument::Event interface more, namely adding methods to get the current state of the objects.

With reference to the previous post, I did not manage to complete the following two tasks:

1. Adding tests for Probe.nqp and EventLibrary.nqp
2. New events (sub call, class events, exception events)

I hope to be able to complete these two tasks by Thursday (June 24th).

For this week, I would like to complete the following:

1. Add events for GC.This is mostly replacing the entries of interp->gc_sys with appropriate stub methods that will raise an event. Hopefully it shouldn’t take that long (Prays for no crashes, since raising the event will invoke the GC itself, methinks).
2. Dynamically remap dynops (Internally, nothing to do with the dynop_mapping branch).To date, I have not been able to successfully run tracer.nqp on perl6.pbc, at least as far as getting to the REPL prompt. This is mostly due to dynops (I think), since dynops used the perl6.pbc are dependent on the order that the dynop libraries are loaded during the compilation of that PBC. I have somewhat of an idea on how to approach this, but have not probed enough to know more details of it (namely in what order were the dynop libraries loaded, and how to remap the dynops to the op table). Hopefully it will be successful.
3. Prepare to instrument the PMC Vtables.
   After discussing with cotto, it would be better if I do this first while waiting for the dynop_mapping branch to merge.