smspillaz/gjs-coverage — pull request #2 by smspillaz (2013-12-24 13:38:00+00:00)
Title: Issues/1

This is pretty close to what I want to submit upstream.

I'm looking for a very basic review here just as a double-check. It will require a little bit of refactoring when I do integrate this with upstream Gjs, as the gjs function profiler needs to be integrated to use GjsDebugInterruptRegister.

A very quick rundown of the overall architecture:

SpiderMonkey (the engine used for Gjs) has some hooks available for debuggers to receive notifications and alter program flow. Those hooks are:

1. Receive notifications when a new script is loaded
2. Receive notifications when we enter a new function or script
3. Optionally enable single-step mode and receive interrupts for every new instruction
4. Set and insert breakpoints and receive a notification when one is hit.

GjsDebugInterruptRegister (and the interface provided through GjsInterruptRegister) is a central station for all debugger-like functionality to add and remove hooks from SpiderMonkey without having to know the details of SpiderMonkey. It automatically handles setting up the individual callback hooks and deactivating them when no-longer needed. It also provides information in the hooks in a way that the user would expect as opposed to providing SpiderMonkey internals such as JSScript and jsbytecode for program counters.

Users can add new hooks by calling one of the functions on GjsInterruptRegister with a callback. This returns a GjsDebugConnection. Once users are done with the hook, it can simply be removed by unreffing the connection. It will call-back into the interrupt register on its finalise handler and make sure that the SpiderMonkey hooks are removed there as well.

GjsCoverage is simply just an object that uses a GjsInterruptRegister to get callbacks on every step and records that information to a file that genhtml will understand.

One very obvious question would be "why didn't you use signals for this?". The answer is that there is no notification for the signaller when a a signallee is connected, which we absolutely need if we want to manage the SpiderMonkey hooks properly. Thus, our own system of callbacks takes its place.

Tests have been added for most of the major functionality.