Visually debug for 8051 under Windows using DDD/SDCDB/S51

From SDCC wiki
Revision as of 23:03, 4 December 2012 by Borutr (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

The SDCC manual chapter 5.1.6 inidicates, that the ddd visual debugger front-end can be used with sdcdb/s51 to debug visually sdcc-x51 programs. However, ddd is *nux-only, as it is bound to X-Window. Recently, X-Windows have been added to Cygwin, and that opened a new opportunity. I'd try to go through all the obstacles and succeeded to run ddd with sdcdb on a Windows Vista SP2 machine. Don't be overly optimistic, though, this is a rather cumbersome and heavyweight path. See also the caution below at item 4. Here are the details:

1. Install SDCC "normally", making sure the appropriate paths to sdcc binaries are set to the command line environment. Create some working directory, write some simple program (I simply copied [SDCC]/device/examples/mcs51/simple/hi.c to my working directory) and compile it with the --debug switch (sdcc --debug hi.c).

2. Install Cygwin/X. The hints are in http://x.cygwin.com/docs/ug/setup-cygwin-x-installing.html . Basically, run a "normal" Cygwin installation, and make sure you select xorg-server and xinit in the installator (its response to wild clicking is rather slow, be patient). Don't proceed yet with Cygwin, goto item 3. below... :-)

3. ... in the same installator, select to install also ddd . It will select some required libraries automagically.

4. Proceed with the installation. CAUTION. Don't even attempt this without access to fast and unlimited internet connection and enough free disk space. For me, it downloaded more than 1.3GByte data, and the resulting cygwin directory is almost 5Gbytes. It surely can be tuned up: the installator pulls a lot of unnecessary applications and their libraries and kin; but I simply cannot tell what is needed from it and what is not.

5. Wait. For me, it took another two hours after the download until the installator did everything it wanted to do. Don't be surprised if it installs some garbage icons on the desktop as it was for me :-( but at least the Start menu contained (among others) the Cygwin-X directory.

6. From Start menu, run Cygwin-X. Wait. It creates an "X" icon in the right icon tray, and, after more waiting, it opens a window with the shell. At this point, some rudimentary experience with *nux or at least with command line tools is needed. Note, that the root directory inside Cygwin is equal to Win directory where Cygwin was installed, typically C:\cygwin. So we are now in our $HOME directory, which in Cygwin is /home/[YOUR_NAME], in Win it is C:\[cygwin]\home\[YOUR_NAME]. To break out from cygwin to the Win directory system, cygwin provides a /cygdrive "directory" containing all the Win drives. So, a C:\Programs\SDCC Win directory is /cygdrive/c/Programs/SDCC in Cygwin. Try to go up and down on the directory structure in Cygwin using the cd and ls commands to get a grip of what is happening.

7. As sdcdb runs as a Win application and ddd as a Cygwin one, they see the directory structure differently. This different notion of paths makes unpractical to try to run if from anywhere else than from the working directory, where we have all the sources and files resulting from compilation at one place with no need to go elsewhere in the directory structure (to understand this took me quite some time and experimentation... ;-) ). So, if your working directory from item 1 was say C:\Work, in the Cygwin/X window do cd /cygdrive/c/Work.

8. A happy moment: ddd -debugger "sdcdb hi" ("hi" here is the name of your program but with no file extension - mine was hi.c) Wait. Wait. Wait. Voila!

9. It has its limitations, of course. Source code and disassembly display and breakpoints and run/step work (mostly). Could display registers but not memory. The fonts are ugly and some windows can't be resized so you need to scroll up/down or left/right to see everything. Don't know how to redirect IO. Some commands make the whole stuff crash; the aftermath is that you need to inspect in TaskManager within processes if s51 (and sdcdb itself) are not still running and if yes, kill them manually.

ddd_example.png

Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox