GSoC 2011 Parrot Debugger

Tue Mar 29 13:17:32 UTC 2011

I have several comments! Before I post them I just want to reiterate
one point: I wouldn't put in the effort to read your proposal and
write all these comments if I didn't think it was worthwhile. Your
proposal is very good right now, and I think it can become even
better.

1. It would be a good idea to mention your intended infrastructure. Are you
going to host your code on github (recommended)? What will be your build
system, distutils or make? What will you use for testing?

2. What language will you be writing your higher-level components in? I see
NQP mentioned in a few places, is this your target language of choice? It's
good to be explicit.

3. As a general note, the FileHandle.readline method can optionally use
GNU Readline if you built it into Parrot. This will save you from writing any
special code for the purpose.

4. The garbage collector should automatically handle reclamation of unused
Strings and PMCs. Leak detection is therefore probably not too important in
the first phases of this project. You could attempt to place a watch on an
individual PMC, and alert the user when it is collected and recycled. This
would help tremendously with certain types of memory bugs.

5. In "Project Details" point 8, you mention the "state of the stack". Parrot
is a stack-less VM. There are no stacks. Instead, we have a "backtrace" and
a context graph, which you can print out information about.

6. In your timeline, you should include milestones related to testing and
documentation. For example, you could include a count of raw tests ("Will have
at least X tests completed at this time"). Also, you could explicitly state
that a given feature is not considered "complete" until it has been rigorously
tested and documented. If you are going to follow a strategy of design first /
code second, you could use TDD and write your tests first during the design
periods, then write code to make those tests pass. When all tests from the
design period pass, you know your code milestone is complete.

7. I would like to see some of your weeks broken down a little bit further.
Related to point #6 I just mentioned, how do you know when each milestone is
complete? For each week, how do you determine success?

8. You mention several commands, but I only really see "backtrace" mentioned
on the timeline. Can you give a list of commands you plan to implement, and
put them in some kind of order (either logical order or priority order) so we
know what features are going to be available at what times? Lists are good,
so when you finish one thing everybody knows exactly what is next.

9. I suspect backtrace will not take 2 weeks. the CallContext PMC has a
backtrace method which provides an array of hashes with valuable information.
Likewise, the Exception PMC contains a backtrace method and an annotations
method which you could either use or borrow code from to get most of the
logic you are interested in. Factoring out common code from these places into
specialized functions in src/debug.c might be a great first step, and a
little mini project you can work on before GSoC even gets started.

10. Why would we need an XML backend for backtraces? We could take a backtrace
object (either returned by CallContext.backtrace or created custom) and pass
that to an arbitrary serializer. We already have a JSON serializer, for
instance. A pluggable architecture which allowed custom backends is much more
valuable than a hard-coded XML output feature.

11. You mention you are going to design a framework for running code on Week 5
but you aren't working with Parrot-Instrument until Week 7. Parrot-Instrument
provides tools for creating and interacting with runloops, which you could
build upon much earlier in the project.

12. Can you give us any indication about how your system is going to be
architectured? For instance, a system that separates the user-interface from the
actual runloop and debugger logic would be great, because then
different users can
replace the UI with their own tools. Think forward to a time when we
will be creating
graphical tools on Parrot, and somebody wants a graphical  front-end to your
software. How pluggable do you expect the system to be? Will you use something
like MVC?

13. This is a note for me (and maybe cotto): We have to get Parrot-Instrument
working perfectly so Kevin can make use of it! I'll play with that
today. It will be up
and running perfectly (even if we have to cut out some old dead
features) by this
weekend at the latest.

Great work so far!

--Andrew Whitworth

On Mon, Mar 28, 2011 at 10:10 PM, Kevin Polulak <kpolulak at gmail.com> wrote:
> 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.
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev
>
>