After some helpful criticism from the wonderful whiteknight, I have come up with an improved and revised proposal for the Parrot debugger. Let me know what you guys think.
Kevin Polulak Contact Information: Email: [email protected] Google ID: kpolulak IRC: soh_cah_toa New Parrot Debugger: A new debugger that will have the ability to set breakpoints 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 project will include unit tests, code examples, and documentation. Project 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. - All code will be hosted on a GitHub repository ( https://github.com/soh-cah-toa/pdb). 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 software development cycle will follow the traditional waterfall model: requirements analysis, software design, implementation, testing and verification, and maintenance. However, it would be more appropriate to combine the implementation and testing steps together. During this step, I would like to follow a test driven development model: add test, watch test fail, write code, watch test succeed, and refactor. Using a hybrid of these two models, I think it will be clear what is expected beforehand and will ensure that no bugs will grow exponentially throughout development. - 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. - During the design phase, a rough draft or outline of user documentation will be written as well using POD. The final documentation phase will take place during the last two weeks. The unit tests will also be designed during the design phase. - 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 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 (obviously) 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 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 (outline/rough draft). * 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 (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 – Finalize user documentation. Add examples. - Week 12 – Finalize user documentation. Add examples. - 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 (obviously) use both of these on a regular basis and have a basic understanding of how the 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. 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. 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. 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 meet both Google's age and student requirements. If needed, I can provide identification and documentation upon request.
_______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
