GSoC 2010 Idea: Instrumenting Framework

[Muhd Khairul Syamil Hashim]

Hi there,

I should introduce myself.
My name is Khairul and I'm currently a Year 3 student studying at the
National University of Singapore (NUS), majoring in Computer Engineering.

I currently have an idea for the 2010 Google Summer of Code (GSoC 2010),
which is to implement a simple framework for instrumenting code that runs
on Parrot. This is in the vein of DTrace and DynamoRIO (a dynamic
instrumentation tool platform, www.dynamorio.org).

I think having such a tool will be a boon to Parrot and languages that
implement on top of Parrot. With instrumentation, we can inspect the flow
of the program dynamically, setting up triggers on certain environment
conditions, etc. This will assist in debugging the system, potentially
providing more information than just debugging or tracing the program.
This can also serve as a basis for more tools, with Valgrind  and its
tools as an example.

As such, this is my proposal. I would like to embark on a project for
GSoC to create a tool that will take in 2 arguments, the first is the
source file to execute and instrument against, and the other, a file
containing the instrument callbacks that will be called on certain events.
The tool will consist of 2 Parrot interpreter environments, one to run the
file and the other for the instruments. This will prevent the instruments
from contaminating and interfering with the execution environment. By
utilizing an interpreter for the instruments, we can use languages supported
on Parrot to implement the instruments. I think the tracing runcore can be
leveraged and modified to provide the hooks for calling the instruments,
given that it is already tracing and dumping all instructions.

                                   +---+ +---+ +---+ +---+
                                   | A | | B | | C | | D |   <- Various
+------+                           +---+-+---+-+---+-+---++   instruments
| Code |                           | Instrument Interface |  <- Interface
+------+------+                    +----------------------+   to register
| Interpreter |  ----------------> |      Interpreter     |   callbacks (PIR)
+-------------+  Hooks activated   +----------------------+
 [ Hopefully the diagram doesn't get garbled ]

Of course, this is a simplistic overview.I shall admit that I have only
recently started looking at Parrot when I heard about the announcement of
GSoC 2010. As such, my understanding of Parrot and its internals may not
be sufficient for now. I have spent the past few days looking through the
source for Parrot and suspect will spend more time over the coming days,
classes and workload permitting, figuring out Parrot's internals and PIR.

I would greatly appreciate any thoughts or comments regarding this.

Regards,
Khairul
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev

[Jonathan Leto]

Howdy,

This looks like a start to a good proposal, Khairul. Could you provide
some specific examples of what kind of instrumenting code you could
get done by the end of the summer? I invite you to #parrot and
#soc-help on irc.perl.org to get more feedback from developers. As
always, if you have questions about Parrot internals, send questions
to this mailing list.

Duke

--
Jonathan "Duke" Leto
jona...@leto.net
http://leto.net
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev

[Muhd Khairul Syamil]

Hi Duke,

Thank you for the invitation to the IRC channels.

I do intend to get on there when I have the time.

With regards to your question, I can't give any firm examples for now.

I'm still learning about the Parrot internals and PIR. I will try to answer that

question soon.

However, I have, over the past 2 days been working on a proof of concept,

which does simple instruction counting of instructions executed.

I'm not certain if its a good idea to attach the code, so I'll just post the link.

http://www.mangkok.com/parrot/doctor.c

http://www.mangkok.com/parrot/instr.pir

Doctor.c is the C source file.

Compiled, it takes in 2 arguments, as I stated in my initial posting,

the first of which is the .PBC file of the instruments, the second of

which is the .PBC file of the code.

(I can't  figure out why it doesn't seem to be able to compile .PIR files)

(Tested on Mac OS X 10.6, don't have access to linux for the moment)

instr.pir is the PIR source code for the instruments.

Well, so far, I've only implemented a simple instruction counter instrument

that counts the number of instructions executed. The count does seem to

tally with the instructions counted in pbc_disassemble's output of the file

I tested on. Performance wise, it is kind of slow. But it is a start.

(Tested on my own .PBC files and the compiled .PBC of mandel.pir in examples/pir)

I do apologize for taking a while to reply to you. I am rather swamped with

assignments at the moment, hence the delay.

I would appreciate any comments or suggestions regarding the proof of concept.

Regards,

Khairul

[Muhd Khairul Syamil]

Hi there,

I've written up a more detailed proposal on my proposed
instrumentation tool for GSoC. It can be found at
http://www.mangkok.com/parrot/parrot_proposal.pdf

I would appreciate any comments on it.