HBDB Closed for Construction, Please Use Detour

This past week was admittedly dull. I've reached a bit a road block and this time it's blocking the way forwards, backwards, left, and right.

IMCC has proven to be quite problematic and has been the source of much of my frustrations. Honestly, I really don't see how I can implement breakpoints at all because IMCC does such a poor job at accurately tracking line numbers. Yes, I realize that I can use the program counter instead but 1) I need to have support for line numbers eventually and 2) IMCC doesn't seem to play nice with the program counter either. Frankly, IMCC has significantly crippled my project since a lot of the more advanced features I wish to implement rely on breakpoint operations behind the scenes.

Because of this, I'm really not sure if I'll be able to fit parrot-instrument into HBDB; at least not during the summer. I haven't really looked at it because I've been focusing on other things. There are some more important things that need to happen first.

One of these things is the run and step commands. These two commands behave very similarly. Essentially, all they do is manipulate a few status flags to indicate whether or not to continue execution and also how to resume execution. I described the problems I was having with this in my last post and have made some headway. Some. The run command is fine but now step only works if you run the run command at least once. This makes me 100% sure that there's some flag that's only being set by run but not step. Unfortunately, fixing this is not just a matter of looking at the difference between the two commands because the same status flags they manipulate are being tested and set and cleared in many other places. Trying to fix these two commands has actually been one of the most annoying tasks I've had to do so far...and it's still not right.

Another blocker is the exit command...still. This command was working perfectly fine until soh-cah-toa/hbdb was merged into master. Now it just segfaults and causes the program to crash. I've tried a handful of different solutions and just can't seem to get it to behave properly. Well, I've just been ignoring it for the time being until I can get some help with it. Unfortunately, this creates a problem: I can't write any more tests. Here is a generalization of how most of my tests work:

Open filehandle with open3()
Write command to filehandle
Close filehandle
Compare actual output with expected output

Simple, right? Not quite. The Close filehandle step stops HBDB by sending it EOF. However, like I said, exiting HBDB causes a segfault and so the actual output in the last step will always contain Segmentation fault (core dumped).

Although not quite as important, parsing command-line switches for the debugee program does not work properly either. Take the following command:

$ hbdb --foo hello.pir --bar --baz

How I'd like this to work is for --foo to be interpreted as an HBDB switch while --bar and --baz would be interpreted as switches for the hello.pir file. Basically, anything directly after hbdb should be interpreted as an HBDB switch and anything after a filename should be interpreted as a switch for that particular program. Invoking HBDB like this though causes a segmentation fault. What a surprise. I think this is just because longopt is very basic. I'm going to try using getopt() instead and if that doesn't work, I guess I'll just have to swim through miles and miles of pointer arithmetic and do it myself.

Now, if your name begins with a "D" and rhymes with "Monticello", you are probably thinking "I suggested he write a modified timeline. Why don't I see it?" Well, the truth is I really don't think I can accurately or even approximately predict where HBDB is headed. There are several reasons why but the main one is because of the unforgivable sin some Parrot developers committed long ago by writing IMCC. When I wrote my initial timeline, much of it turned out to be inaccurate because I had no idea 1) how excessive the learning curve for Parrot's (internal) code base is and 2) just how obnoxious and utterly horrendous IMCC really is.

The first point is something that I actually plan on helping to reduce once the summer is over. Though it's not really relevant to this blog post (but if you're curious, it's due to a lack of consistency). The second point is something that is far out of my reach to fix and (from what I've heard) also out of reach for most of the other Parrot developers. There is no solid effort to fix or maintain or repeatedly bash with a hammer and re-write IMCC. Therefore, it's going to just sit and continue to cause problems for HBDB (and many other projects). Sorry Duke...uh...I mean, Monticello. ;)