Started a new debugger

I recently decided that I had spent too much time trying to cope with the problems involved with using various IDE's and debuggers.  I had good success with ddd though it would have been nicer is my pygtk dialog would have added a variable to the ddd data window.  Then I started experimenting with Windows.
I found python along with 64 bit versions of gcc and gdb for windows.  The gdb did not have an internal python interpreter.  So I decided to bite the bullet.



Python is distributed with Tkinter as the standard GUI toolkit, so I did my best to forget about pygtk and set about learning Tkinter, python and gdb in more detail.  The goal is to have a GUI written in python which runs gdb using the python subprocess.Popen function to connect gdb where the python code can write commands to gdb and read whatever gdb writes.

Rapidly I discovered that I needed the gdb prompt to include a new-line character so that I could use readline to read the output of gdb.  This works very well though the interface is clearly a kludge.

I discovered from the kdbg source code that they used a small trick with xterm to keep the xterm window alive.  Their code had xterm run bash as the command to execute and they had bash run a small script file.  I adapted this idea to run xterm all from command line parameters:

    xterm -e bash -c "tty > /tmp/gdb_user_1234; \
          trap '' INT QUIT TSTP;exec<&-;exec>&-;sleep 7200"

The tty command is to identify the pseudoterminal device for the xterm window so that this device name can be passed into gdb with the -tty option.  The /tmp file is a named pipe incorporating the python process id which is read by the python code after the xterm process is started.

So far I have my GUI (named ydb) displaying a source window, a console window and a data window.  The source window shows each line of the source file being debugged and has spots to the left of each line to show a red ball for each breakpoint and a blue arrow for the next line to execute.

This window looks fairly decent.  It uses buttons for everything which works pretty well.  I would be happier without the "grid" in the first 3 columns, but I prefer the color difference between the source and the first 3 columns.  It might be nice at some point to get an artistic friend to offer some style suggestions.

The data window is quite crude right now.  It does show the 16 basic registers fairly well, but much more is needed.

The data window will need a toolbar and some icon/buttons to make it look nicer.  The "Hex/Dec" button does toggle the register format between decimal and hexadecimal.

The console window is pretty pitiful looking at this point.

The buttons work, but they need to be transformed into icons.  The label is part of some test code.  I also have a status bar at the bottom of the window.  I was experimenting with having one stretchable, scrollable portion of the console window.  Eventually I plan to provide a text entry line to allow feeding commands directly to gdb and I want to have all the gdb output be placed in the scrollable region of this window.

There is a lot to do, but this is coming together nicely for about 3 days effort.  It is capable of debugging assembly code fairly well.  It can debug C/C++ code though I need to watch locals and function arguments to improve it a bit more.  Eventually I will prepare a list of variables obtained from parsing the .asm file which will be available for watching in the data window.  I will also allow entering variables based on addresses observed in the debug session for data on the stack and the heap.  At this point ydb will be an improvement over the alternatives for debugging assembly code.

I had a brief encounter trying ydb with windows earlier today.  I learned a few things and I will be better prepared on the next attempt.  I think I have learned enough to prepare a GUI interface to gdb which will be quite portable.  There are a few places where I need to use os.name to determine if I am on a Posix system or not.  There are no other choices worth worrying about.

Perhaps some people would prefer using Visual Studio under Windows, but I have gotten tired of reading about Windows.  It will be easier to write my own debugger than to learn how to use masm and VS.  Writing my own debugger offers some interesting opportunities for future efforts.  I can imagine beefing up a set of loadable modules for educational purposes for C++ and assembly language.