The Trouble With Debuggers

Feb. 3, 2005
You know what has bugged me for years? Software debuggers, the applications engineers use when debugging anything from embedded systems to server applications and beyond. Now, don't misunderstand me, my livelihood depends on these things and

You know what has bugged me for years? Software debuggers, the applications engineers use when debugging anything from embedded systems to server applications and beyond. Now, don't misunderstand me, my livelihood depends on these things

and the need for them. But we're living in the 21st century. Debuggers are still back in the 20th.

Take a look at any debugger, whether for an embedded system or not. Look at the screen that the software designer is using. Now, let's go back in time to the 1980s, where we find DOS, not even Windows 3.1. (Was there ever a Windows 1?) Look at the old DEBUG under DOS. All the input and output is ASCII. Simple and direct, a combination of alphanumeric characters provided the information on what the system under test is doing.

Okay, fast forward to the 1990s. This thing called a GUI or graphical user interface is added to the debuggers. Graphical? Yes, there are multiple movable windows. Each window contains ASCII. Alphanumerics. That's it. No G, only the same old UI. Now fast forward to 2004. Look at a debugger. Wow, what do you know? Same old, same old.

Here's an earth-shattering idea. Let's use a vertical bar graph, a single bar, to show the stack. Set the maximum stack size, and after every step or every time the screen refreshes, the bar shows how much stack is being used. Now, isn't that a lot easier to understand than knowing the stack pointer is at 0xFF030? Now, let's go crazy. Let's make the bar turn red if the stack only has 10% of its space left. How about if it blinks if it overflows? What if there is a different color for each stack frame? Or at least a line. Now I can see that I am three frames into it and the stack is full. Hmmm, a bit of that "G" entering the GUI. The horror.

"I" is a very simple letter. Many compilers automatically assign a variable called "i" to a register variable because we all use it for loops (for i = x to y...). So here I am debugging an average algorithm, let's say programming Einstein's theory of relativity in Cobol. My mind is in the midst of the whole time, distance, mass, and energy thing when I need to know where I am in my inner loop. Today's debuggers, similar to the one Einstein himself is said to have used, would show me that "i" is equal to 43. I now need to mentally push on the stack the time-continuum things I am trying to debug and figure out what percent of my i = 13 to 64 loop is complete. How about a simple horizontal status bar? The compiler and debugger know the start and end values.

Don't get me wrong. Some debuggers do have G in their GUI. One that we all use (I won't mention any names here so as not to get a legal letter from Bill) uses graphics in an interesting manner. All debuggers need a way to single step code, to "run" code, and to set break points. Basic stuff.

When the GUI operating systems came along, the only graphics to make it to debuggers were on fancy little buttons. I can understand why some people think it is easier to find and click on a button than it is to hit the letter S on the keyboard for a step.

But now I have several buttons in front of me. Some have curly brackets with arrows going in and out or just in, or just out. And how about that little white square with an arrow pointing down next to it? Which one is for a step? Why not have a button that says "STEP"? Or a button that says "GO"? My favorite debugging pastime is trying to figure out if it is the little flag, the hand seemingly saying stop, or the red exclamation point that will set a break point. Or go to one. Or go past one. Or stop the processor from running. Really, which takes more space: writing BR, STOP, or GO or making a fancy, meaningless icon?

Next time you are at an embedded tools conference or the Debuggers-R-Us conference, walk over to any debugger mid-demonstration. Without saying a word, try and understand anything on the screen. Anything. If you can, buy it! If there are any honest to goodness engineers running the demo, ask them to show you the graphics capabilities, other than a window that moves. They're just not there. Maybe in Longhorn....

Sponsored Recommendations

Highly Integrated 20A Digital Power Module for High Current Applications

March 20, 2024
Renesas latest power module delivers the highest efficiency (up to 94% peak) and fast time-to-market solution in an extremely small footprint. The RRM12120 is ideal for space...

Empowering Innovation: Your Power Partner for Tomorrow's Challenges

March 20, 2024
Discover how innovation, quality, and reliability are embedded into every aspect of Renesas' power products.

Article: Meeting the challenges of power conversion in e-bikes

March 18, 2024
Managing electrical noise in a compact and lightweight vehicle is a perpetual obstacle

Power modules provide high-efficiency conversion between 400V and 800V systems for electric vehicles

March 18, 2024
Porsche, Hyundai and GMC all are converting 400 – 800V today in very different ways. Learn more about how power modules stack up to these discrete designs.

Comments

To join the conversation, and become an exclusive member of Electronic Design, create an account today!