GSoC 2011 Parrot Debugger

Kevin Polulak kpolulak at gmail.com
Tue Mar 29 02:10:14 UTC 2011


Here's what I've got so far. Please give me some feedback.


Kevin Polulak

Contact Information:

Email: kpolulak at gmail.com
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:

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

2. Add an interface for code instrumentation and introspection.

   - This would not take very long as I can just borrow the code already
      present in parrot-instrument.

3. Create an extension that would open an interpreter and be able to run
code within it one opcode at a time.

4. 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 GNU Readline to make command shell a little more friendly. This
      would add command line editing, command history, and tab completion.

5. 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.
      - There's much, much more that can be added in the future. These are
      just a few.

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

7. Memory error detection.

   - Check arguments to function calls for uninitialized or invalid values.
      - Detect leaks by keeping track of all dynamically allocated blocks
      issued through a call to new().
      - NOTE: I am not sure if this is the responsibility of the garbage
      collector or not. If it is, well then we obviously won't need this.

8. An enhanced backtrace with the ability to take a "snapshot" of the
current state in the program's execution.

   - This would log information such as the state of the stack, list of
      symbols and the values, etc.
      - It may be a nice addition to export the report in a nicely formatted
      XML file. With XML Schema, this may not take more than a few days.

Timeline:


   - Week 1 – Program design and outline. Plan which commands to implement
   first.


   - Week 2 – Begin writing code for basic command set and shell.


   - Week 3 – Continue developing commands. Begin designing backtrace.


   - Week 4 – Begin writing code for backtrace.


   - Week 5 – Design framework for owning an interpreter for running code.


   - Week 6 – Begin writing code for interpreter.


   - Week 7 – Integrate parrot-instrument for instrumentation functionality.


   - Week 8 – Design algorithms for memory error detection.


   - Week 9 – Begin writing code for memory error detection.


   - Week 10 – Design XML format for “enhanced” backtrace.


   - Week 11 – Write code for “enhanced” backtrace XML report


   - Week 12 – Reserved if things take a little longer


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

Outside of writing code, some of hobbies are reading books, playing
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.parrot.org/pipermail/parrot-dev/attachments/20110328/360e9294/attachment.html>


More information about the parrot-dev mailing list