Create a gist now

Instantly share code, notes, and snippets.

What would you like to do?
GSoC 2011 Parrot Debugger Proposal
Kevin Polulak
Google ID: kpolulak
IRC: soh_cah_toa
A new Parrot debugger that will have the ability to set breakpoints at specific lines and on subroutines at the PIR and
HLL level and set watchpoints on registers or individual PMC's. It will provide code instrumentation and be able to
introspect state information from running code. The debugger will read debug information and annotations so that it can
be used to work with all Parrot-supported HLL's.
Parrot's user base consists of many people engaged in the development of dynamic programming languages (e.g. Rakudo
Perl 6, Lua, and Winxed). Additionally, the new debugger would be a great asset to the Parrot developers themselves.
As the current state of Parrot's debugger is quite buggy, most Parrot developers and programmers generally do not use the
debugger. The new debugger will provide them with an easy way to debug their code without the use of method stubs or dummy
The new Parrot debugger will be both an incremental improvement and an aggregation of existing tools.
A working debugger with the features listed below. Additionally, the debugger will include unit tests, code examples, and
user documentation.
* General Details *
-- All code will be hosted on a branch off of Parrot's GitHub repository. Once the project is finished, it will be merged
back into the master branch.
-- The build system will make use of Parrot's distutils. That being said, it would make sense to use test_more.pir for
writing unit tests.
-- The development process will follow an iterative and test-driven development model. First, we will identify and
prioritize the commands/features that will be implemented each week. Then we will design and write the unit tests
(documentation will take place at this point as well, explained below). Initially, they will fail. Then write the code
that will cause the unit tests to pass. Repeat. I think this approach will make it clear what is expected beforehand
each week and will ensure that no bugs can grow exponentially throughout development.
-- As most programmers already know, poorly written documentation can make using software a nightmare for both the user and
developer. That's why I feel that it's important to take the time to properly document the new debugger. During the design
phase, a rough draft or outline of user documentation will be written using POD. After coding has finished for each
command/feature, the final documentation will be written including examples. The unit tests will be designed during the
design phase as well. This way if things are running late, the documentation and examples still get done. As always, all
code will be properly commented.
-- All code will be written in a mixture of C and NQP depending on which language can accomplish the task more easily. A
large portion of the code will probably end up being NQP.
* Specific Details *
-- Read bytecode annotations and debug data from currently running code.
- This would effectively extend the debugger's "vocabulary" from PIR to all Parrot-supported HLL's.
-- Add an interface for code instrumentation and introspection.
- This would not take very long as I may just borrow the code already present in parrot-instrument.
-- Create an extension that would open an interpreter and be able to run code within it one opcode at a time.
-- Implement a shell as a user interface. Will be able to able to interpret commands, display information about current
location, etc.
- This may as simple as an NQP eval loop with a global dispatch table for user commands.
- Use the FileHandle PMC to make the command shell a little more friendly. We can also add command line editing,
command history, and tab completion.
-- A basic command set would include things like:
- Start and continue execution with the ability to add arguments if they're not specified on the command line.
- Creating breakpoints at a specific line or function.
- Watch Parrot registers (including PMC's).
- Stepping through code by executing either a single PIR opcode or executing all PIR opcodes until the next
annotation line change.
- Changing the current working directory of the program.
- Backtrace. Use the CallContext and Exception PMC either directly or borrow code as an outline.
- There's much, much more that can be added in the future. These are just a few.
-- Trace all open file descriptors.
- This would also mean it'd have to trace all child processes by following calls to execve(). This is simple.
-- Dynamic memory analysis.
- Check arguments to function calls for uninitialized or invalid values.
- Place a watch on all or individual PMC's to detect when it has been reclaimed by the garbage collector.
*NOTE* To avoid redundancy, referring to "design" here will imply code design, unit test design, and documentation design.
At the beginning of each week, there will be a discussion with the mentor(s) to make a weekly outline and a set of goals
describing what needs to be accomplished each week. This can be considered the "requirements" step in my waterfall model.
Week 1 - Begin designing initial set of commands. A good starting point would be: enable/disable breakpoints, start/continue
execution, stepping, print registers, source listing, help, etc.
Week 2 - Begin writing unit tests for basic command set and shell. Once the unit tests are in place, begin writing code for
commands. Verify that unit tests now pass.
Week 3 - Begin designing backtrace command. Once the unit tests are in place, begin writing code for backtrace. Verify
that unit tests now pass.
Week 4 - Begin design and plan how to integrate parrot-instrument. This may mean borrowing code directly or using it as a
guideline. Once the unit tests are in place, begin writing instrumentation code. Verify that unit tests now pass.
Week 5 - With parrot-instrument in place, design framework for owning an interpreter for running code.
Week 6 - Begin coding phase for interpreter. Once the unit tests are in place, begin writing code. Verify that unit tests
now pass.
Week 7 - At this point, it may be best to add a few more advanced commands. This could include: bytecode disassembly
(possibly with pbc_dump), scripting (for instance, interpreting a file as a set of debugger commands), print
information about interpreter, etc. This week would be spent on the design.
Week 8 - Begin coding phase for new set of commands. Once the unit tests are in place, begin writing code. Verify that
unit tests now pass.
Week 9 - Begin design of commands for dynamic memory analysis.
Week 10 - Begin coding phase for dynamic memory analysis. Once the unit tests are in place, begin writing code. Verify
that unit tests now pass. This may not take too long so if things get finished early, get a head start on
Week 11 - Review documentation and code examples. At this point, it should be complete but if it's necessary, we can
always include some more examples and documentation.
Week 12 - Review code before submission. Go over it with a fine-tooth comb, so to speak.
Week 13 - Reserved if things take a little longer.
whiteknight and cotto are both listed as possible mentors. I have brainstormed with both of them about the debugger
project. Whiteknight has mentioned that he will most likely end up being the mentor for this project.
Artistic License 2.0
This is my first Google Summer of Code as well as my first open source project. The languages that I have the most
experience with are C and Perl. I have been using both for approximately 4 years. There are a few others - Java, for
instance - but being a Linux hacker, C and Perl are my two comfort zones. I don't have much experience writing
compilers/parsers or debuggers but I do use both of these on a regular basis and have a basic understanding of how
they work. However, that is the direction I would like to go with my career which is why I am very interested in Parrot.
To be specific, I consider gdb and perl -d to be one the most frequently used tools in my little handy programmer's
Besides writing code, some of my hobbies are reading books, studying blackjack, and spending time with my cats. I also
volunteer as a feeder and foster parent for a local organization called Care and Treatment of Strays (C.A.T.S.) that
feeds and provides medical treatment for stray cats.
I have never worked on a project of this size before but I have done very well working on group projects at school. It
is not hard for me to take command of a project and I am very good at splitting up the workload and assigning roles.
I can easily play the role of either leader or follower.
I feel that I would make a very good candidate for this project. I have a very strong desire to give back to the open
source community. This project would be the perfect challenge for me. It is right at the level that would force me to
"stretch" my abilities quite far but not too much that it would be just out of my reach. I have already learned so much
in just chatting with the Parrot developers and I am confidant that the experience I would gain from this project would
be invaluable.
I am responsible, dependable, and honest. I have an incredible eye for detail and will never leave things half finished.
With these traits, I feel that I would make the perfect addition to the Parrot community.
I meet both Google's age and student requirements. If needed, I can provide identification and documentation upon request.

soh-cah-toa commented Mar 28, 2011

Alright. I assumed the template was only for the application I sent to Google. I'll revise it tomorrow.

leto commented Mar 29, 2011

This looks really awesome. Just fit it into the template, and add a detailed timeline. If you have stuff you already wrote that doesn't fit in the template, just add an "Extra" section at the bottom.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment