GSoC 2011 Parrot Debugger Proposal

gsoc2011_pdb_proposal

Kevin Polulak

# CONTACT INFORMATION:

Email: kpolulak@gmail.com
Google ID: kpolulak
IRC: soh_cah_toa

# NEW PARROT DEBUGGER:

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.

# BENEFITS:

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 
code.

The new Parrot debugger will be both an incremental improvement and an aggregation of existing tools.

# DELIVERABLES:

A working debugger with the features listed below. Additionally, the debugger will include unit tests, code examples, and 
user documentation.

# PROJECT DETAILS:

* 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.

# TIMELINE:

*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 
          documentation.

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.

# REFERENCES AND LIKELY MENTORS:

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.

# LICENSE:

Artistic License 2.0

# BIOGRAPHY:

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 
pocketknife.

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.

Make sure you follow the template: http://trac.parrot.org/parrot/wiki/GSoCStudentApplicationTemplate

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

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.