Instrumenting Parrot

Done this week:

1. Added in generator scripts.
   cotto suggested it would be a good idea to put the scripts I used to generate the stubs in tools/build, so that got done. That done, I added a way to get at the parameters passed to the vtable and GC functions. The example below show’s what I mean:
   test-invoke.pir

   .sub '' :anon :load :init
       load_bytecode 'Instrument/InstrumentLib.pbc'
   .end
   
   .sub main :main
       .param pmc args
       $S0 = shift args
   
       $P0 = new ['Instrument']
   
       $P2 = get_hll_global ['Instrument';'Event'], 'Class'
       $P1 = $P2.'new'()
       $P1.'callback'('class_handler')
       $P1.'inspect_class'('Sub')
       $P1.'inspect_vtable'('invoke')
   
       $P0.'attach'($P1)
   
       $S0 = args[0]
       $P0.'run'($S0, args)
   .end
   
   .sub class_handler
       .param pmc data
   
       $I0 = data['line']
       $P0 = data['parameters']
       $I1 = $P0
       $P1 = $P0[1]
   
       print 'Line: '
       print $I0
       print ' with '
       print $I1
       say ' parameters.'
       print 'address: '
       say $P1
   .end
   

   test-script.pir

   .sub main :main
       test()
   
       say 'Done'
   .end
   
   .sub test
       say 'Invoke!'
   .end
   

   Which yields the following output:

   Line: 3 with 2 parameters.
   address: 0
   Line: 25 with 2 parameters.
   address: 1006b0050
   Invoke!
   Done
   

   Along the way, I discovered a small bug in src/pmc/pointer.pmc, in line 162:

   return Parrot_sprintf_c(INTERP, "%s", PARROT_POINTER(SELF)->pointer);
   

   Subtle, innocuous looking code, until you realise that it’s supposed to print an address, not a string.

2. Partially implemented Instrument::Event::Class
   The code above shows that it is somewhat working. What is missing is instrumenting methods, removing the hooks, and instrumenting dynamically loaded classes.
3. Massive refactoring of InstrumentGC and InstrumentVtable
   Both InstrumentGC and InstrumentVtable work pretty much the same way. So by refactoring the common code out into InstrumentStubBase, most of the remaining code in InstrumentGC and InstrumentVtable are generated by the scripts tools/build/gen_gc_stubs.pl and tools/build/gen_vtable_stubs.pl. Refactoring the code was somewhat in the back of my mind, and cotto also mentioned it in last week’s meeting with him. Trying to complete Instrument::Event::Class was the thing that spurred this refactoring, as I found out more and more how similar both InstrumentGC and InstrumentVtable is. Along with the refactoring, I took a step back and reevaluated how my mappings for various items were done, well, that got changed too. So did the event dispatcher, again.
4. Not as massive refactoring of EventDispatcher
   So this is the second week that EventDispatcher got refactored again. So now it can pass events such as Class::Sub::vtable::main::invoke, so that’s category, class name, vtable, vtable group and the item itself, which is more flexible that the previous case which was to split it into 3 components.

What did not get done was most of last week’s goals. I got sidetracked into refactoring and ended up not doing the goals. Furthermore, I found out that I need to take into account inheritance when instrumenting the vtable. As an example, EventHandler extends Sub, so when I instrument Sub’s vtable, the stub entries got imported into EventHandler, leading to fireworks that I least expected. Ah well, at least while figuring it out I discovered how to use XCode’s debugger on parrot. So long command line gdb! And good riddance.

Goals this week will be to complete last week’s goals, since this week, week 8 is supposed to be code review, and most of that got covered last week.