Howdy,<br>
<br>
If any of you have been following my GSoC blog, then you already know
that I've faced many frustrations this summer. As much as I hate to
admit it, HBDB is more than likely going to end up rotting in the bit
bucket alongside the old Parrot debugger. This is very upsetting to me.
However, I'm mature enough to realize that this is not necessarily a
reflection of me but more of a reflection of Parrot. However, this does
not mean total failure.<br>
<br>
When I first picked up this project, I searched far and wide across the
Internet in search of any literature regarding symbolic debugging. I
ordered books, I downloaded essays, I chatted with GDB developers, and I
even emailed a professor at University of Southern Maine (I read an
essay of his). None were very helpful. I pretty much just winged it,
playing through the pain this summer. As GSoC comes to an end, I feel
that I've learned a significant amount about how symbolic debugging
works through my endless battle with Parrot. It's maybe not the best
approach to education but effective none the less. The greatest thing
that I've learned is that Parrot is simply not a platform designed for
debugging. This is mostly due to the fact that Parrot bytecode does not
have a real debug segment for storing source-level information about
HLL's.<br>
<br>
It's only natural for areas like this to become neglected in large scale
projects like Parrot. It happens. I want to do something about this. I
really feel that Parrot is part of the future of dynamic languages and
I'm very happy to be a part of it. However, there are many things
holding us back that are preventing Parrot from being seen as a suitable
and adequate alternative to other mainstream virtual machines. As I
discovered this summer, one of those things is a lack of a debug
segment.<br>
<br>
A symbolic debugger really is one of the user-facing applications that
we've been talking about as of recently. Parrot and PCT itself are
attractive to only a very small and largely unknown group of people:
language/compiler developers. If we offer a great debugger to users, the
scope of Parrot will significantly increase. Without it, I really don't
see people (especially Perl 6 interested hackers) switching to
Parrot-based languages when they learn that we don't even offer a
competent debugger they can use. That being said, I think development of
a debug data format is critical to the success of Parrot. (As an aside,
not only would a debug segment be useful for debugging but also for
other analysis tools like profilers, benchmarks, and instruments;
something that's also been a struggle for others to develop).<br>
<br>
Some of the more seasoned Parrot developers are probably thinking, "What
the heck are you whining about? We already have a debug segment." Well,
if you haven't used it then you probably don't realize how utterly
pathetic it is; merely containing a line number to opcode mapping that
is incredibly unreliable. Additionally, our current system of file and line annotations simply isn't enough. What we need is a standardized debug data
format embedded in the debug segment for describing symbolic HLL
constructs such as variables, data types, subroutines, etc. <br>
<br>
That is why I've started designing a debug data format that we can use. The specification is in a Gist located <a href="https://gist.github.com/1133182">here</a>.
For now, I'm calling it SOD: the Symbolic Opcode Description format.
This is certainly subject to change though. I've decided to model it
after the DWARF format since DWARF is considered to be one of the best
formats out there.<br>
<br>
Here's how it works in a nutshell. Since most modern languages are block
structured, the format itself is also block structured. That is, each
entity is contained or "owned" by another entity forming a tree-like
structure. This makes it much easier to describe the static structure of
a source file as most compilers already use a tree-like structure called an
Abstract Syntax tree as an intermediate representation. Only the
information that is needed to describe a program object is provided.
This makes the format extensible enough to describe nearly any
procedural or object-oriented language. A debugger like HBDB could
recognize or ignore certain extensions created by various HLL's.<br>
<br>
The most basic entity in SOD is called a "Data Description Entity" or
DDE. A DDE consists of an "element" that indicates what it describes and
a list of "properties" that further describe the specific
characteristics of the entity.<br>
<br>
More information on the specification can be found <a href="https://gist.github.com/1133182">here</a>.<br>
<br>
I can offer my skills in designing the format itself but a large effort
like this would require the help of many other developers for the actual
implementation. That is why I'm writing this. I would really like to
see some people helping out on this (that includes you, whiteknight). With the time and effort of others, I think this can
really help get Parrot out into user land.<br>
<br clear="all"><br>-- <br>- Kevin Polulak (soh_cah_toa)<br><br>