Paul's Debugger - proof of concept

[Paul Squires]

I have been re-energizing myself over the past two weeks by writing a source code debugger. It sure has been a hell of a lot of fun!

I have attached the program to this post if you would like to see it in action. There is a test source code file included in the package that you can load and debug. No need for you to post here with things that don't work (like Arrays, Pointers, Type elements, multi-file programs) because I am still working on stuff.

It is still in the early stages but the most difficult stuff is already done:
- Code parsing
- Symbol tables
- Watches
- Breakpoints
- Run/Continue
- Step
- Step Over
- Step Out
- Run to Cursor

There are still certain variables that are not parsed yet, and it only operates on a single source code file at this point.

If I can get this working very well then I really want to integrate it into FireFly 4. That would be cool.

Because I wrote the code editor (JellyEdit.dll) that the debugger (and FireFly) uses, it is conceivable that I will be able to implement one the coolest debugging features: Hover over a variable during debugging and see its current value in a popup tooltip. I modeled this little debugger after PB's but maybe I will take a look at other debuggers to see if there are features that I like better. I have already implemented the feature where the Watch variable value will be colored Red if the value changed from its previous value.

Feels good to be enjoying programming again.

[Carl Oligny]

I love it already. If you are able to integrate into FF4, it will give me a big increase in productivity.

[Theo Gottwald]

How do you connect it to PowerBasic?
In the same way the PB Debugger does?

[Marc van Cauwenberghe]

Formidable! Can't wait.

Marc

[Eddy Van Esch]

Paul, that would be a great additional feature for FF !! Great idea!   
Personally, I am even more excited about this then about the Object Framework (although that is very interesting too!).

Before we start flooding you with feature requests for the debugger, may I ask if your debugger concept (I assume you use 'instrumentation' (inserting additional code between each line)) could work with inline assembler code?

Enjoy!

[Paul Squires]

I would expect that I would have to bypass parsing any inline assembler code because injecting code in that area might screw things up. Haven't tried any tests on it yet at this point.

Another area that needs to be addressed is dealing with the PREFIX function in PB. I will need to parse for that to ensure that subsequent lines reflect the PREFIX.

There are so many different ways that things can be coded in PB that I will have to slowly deal with each issue it arises.

(Yes, instrumentation approach is what I used because the PBD file format for the PB Debugger is proprietary).

[Eddy Van Esch]

I would expect that I would have to bypass parsing any inline assembler code because injecting code in that area might screw things up.

In most cases it will indeed. Unless you preserve all register and flag values...

PB provides the "#DEBUG CODE ON / OFF" compiler directive to make sure that inline assembler code is left alone by the debugger.

[David Warner]

This is looking really good Paul. 

I would expect that I would have to bypass parsing any inline assembler code because injecting code in that area might screw things up.

I imagine this wouldn't be too much of a problem for the majority of FireFly Users.

[David Kenny]

I imagine this wouldn't be too much of a problem for the majority of FireFly Users.

I agree with David.  But wow!  I was very hopeful for "Ant Eater"... not sure how many people remember that. I'm glad you picked up the torch!

Might there be any way to leverage your debugger to help figure out the PBD file format? I admit, I don't know enough about it to even know how intelligent this question is.   

David

[Paul Squires]

I remember AntEater. It had a lot of potential at the time because the PB debugger was incredibly slow. I think that Theo tried to get the source code from the author a year or so ago but he wanted an exorbinate amount of money for it. I had started to build a debugger for JPro about 10 years ago. I was looking at that code other day and although the logic/concepts were good, the code itself was horrible!   10 more years of experience has helped me greatly. The new debugger code is very elegant, fast, and extendable.

I tried to decompile the PDB format using some software tools that I have and also some hex editors. You would really need the specification to deal with that format - I couldn't create anything usable from it.

[Marc van Cauwenberghe]

I remember Anteater too. It was very promising. I got into contact with the guy 2 years ago and looked around for people who would be interested in the code. As he made me an offer. It was indeed a large sum of money.

Marc

[Paul Squires]

Ah, yes, maybe it was you Marc and not Theo who pursued that code base a couple of years ago. See, my memory is getting pretty bad as I get older. 

[Douglas McDonald]

I would love to see a debugger more than anything else.

Doug