New Parrot Debugger

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 bidirectional 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. Since NQP was written specially for Parrot development, 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 either forward or backward. Execute either a single PIR opcode or all opcodes until the next annotation line change.

• Changing the current working directory of the program.

• Backtrace using the CallContext and Exception PMC.

• Bytecode disassembly (possibly with pbc_dump).

• Scripting. For instance, interpreting a file as a set of debugger commands.

• There's much, much more that can be added in the future. These are just a few.

• Trace all open file handles.

• This would also mean it'd have to trace all child processes.

• 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:

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

• 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, command scripting, printing information about the 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, making any necessary improvements. 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 and units tests, making an necessary improvements. Go over it with a fine-tooth comb, so to speak.
  

• Week 13 – Reserved just in case things take a little longer.

References and Likely Mentors:

whiteknight and cotto are both listed as possible mentors on the Parrot GSoC Wiki. I have brainstormed with both of them about the debugger project. whiteknight has mentioned that he may 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 never leave things half finished. With these traits, not only will the Parrot developers have gained a new debugger, they will also have gained a fervent and enthusiastic contributor to the community.

I meet both Google's age and student requirements. If needed, I can provide identification and documentation upon request.