feature article
Subscribe Now

Bug-B-Gone!

ARM Programmers Get a New Extermination Tool

What do Netflix movies, embedded programmers, and Raymond Chandler mysteries all have in common?

More on that later. For now, let’s look at a new debugging tool available to ARM users (and they are legion) that helps to find and swat bugs. Just this week, ARM announced that its premium Designer Studio v5 (DS-5) software suite will include a new feature designed by Undo Software. It’s a pretty sweet tool, and one that seems to have a good track record of uncovering hard-to-find bugs and saving programmers time.

Called “application rewind,” it’s a kind of time machine for debugging. We all know about traditional debuggers: you set breakpoints, you single-step, you monitor variables, you follow trace paths. That’s all well and good, but debuggers by their nature capture problems after they’ve happened. You’re then left to do a post-mortem analysis of why and where the problem started. Much of the skill of debugging lies in correctly guessing where the problem might lurk and instrumenting the code accordingly. Guess right, and you locate the source of the bug early on. Guess wrong, and you waste days (or weeks, etc.) exploring dead ends.

What all of these methods have in common is that, in the words of Brian W. Kernighan, you have to “…reason back from the state of the crashed program to determine what could have caused this. Debugging involves backwards reasoning, like solving murder mysteries. Something impossible occurred, and the only solid information is that it really did occur. So we must think backwards from the result to discover the reasons.” [The Practice of Programming, Addison-Wesley, 1999, ISBN 978-0201615869.]

Sound about right? Well, Undo Software thinks it’s tilted the odds in programmers’ favor just a bit. Rather than rely on the old gumshoe method of solving software mysteries, it’s recommending more of a surveillance state; a kind of CCTV for suspect programs. Its debugger allows you to “rewind” code and run it backwards, following it as far back in time as you like, until you discover the root cause of the bug.

It’s a concept that’s been tried before (sometimes successfully), but it’s never before been officially endorsed by ARM. Undo has licensed the debugger, called UndoDB, to ARM for inclusion in the latter’s official DS-5 development suite. Thus, UndoDB will become the de facto debug technology for ARM users who shell out the money for DS-5. For programming teams that don’t use DS-5, Undo is happy to sell them a standalone, retail version of the software.

So how exactly do you run software backwards? By running it forwards, obviously. The details are complicated and understandably secret, but the basic premise is that UndoDB occasionally saves the state of the machine at strategic points in the program flow. When you request a “rewind,” UndoDB reloads the snapshot nearest to the point of interest and then reruns the code from that point, but backwards. It’s essentially like an emulator or instruction-set simulator, but one that “undoes” the results of each instruction instead of emulating their normal behavior.

The magic lies in knowing which CPU operations are deterministic and which aren’t. Adding two numbers together is deterministic, so it’s easy to emulate an ADD instruction running either forwards or backwards while accurately reproducing all of its side effects (such as updating status flags). Reading from shared memory, on the other hand, is non-deterministic: the results depend entirely on what was in memory at the time, so UndoDB takes a virtual snapshot of the system state at that moment. Volatile I/O devices, network packets, and timers are other examples of unpredictable events that require a snapshot.

By cleverly taking snapshots only when they’re absolutely necessary and emulating the rest, UndoDB is able to minimize its impact on system performance while still maintaining 100% fidelity. Earlier attempts at “time machine” debuggers have used the brute-force approach of storing nearly everything, all the time. While that’s reliable, it’s also painfully slow. Undo Software uses the example of the gnu debugger’s “process record” feature, which allows backward tracing but can slow execution by more than 200,000 times. A compression algorithm that takes 10 seconds to run in real time takes 22 days with process recording turned on. Not an ideal debugging tool.

UndoDB is not without its side effects. It also slows execution, but not nearly as much as gdb. In the same comparison, the algorithm took about 38 seconds to run, a roughly 4x slowdown. Clearly, UndoDB incurs some overhead, but it saves three weeks over gdb.

The concept behind UndoDB is a lot like that for MPEG video compression. With MPEG, certain “key frames” of the video stream are compressed, while others are interpolated. That saves a lot of space versus just compressing each frame of video, but it requires a lot of processing power to reconstitute the missing frames in real time. Similarly, UndoDB stores the system state only at certain “key events” in the program flow when it can’t accurately predict what will happen (e.g., a read from an Ethernet buffer). All other program actions are simply reconstructed using known, deterministic information. A beneficial side effect is that the recreated code can be run backwards just as easily as forwards, yielding a useful debug tool.

The tool requires only two things to run: an ARM processor and Linux or a Linux-like operating system. (Actually, that first part isn’t true; UndoDB is available for x86 processors, too.) It’s been tested on Android, Red Hat, and SUSE; other embedded Linux spinoffs like LynxOS may work as well, but they haven’t been tested yet. Specifically, no special compilers, plug-ins, or libraries are needed. UndoDB can work on already-compiled binary code.

UndoDB is no panacea. Anything that slows execution by 4x is going to cause problems when debugging real-time code. And it’s invasive; it requires memory, time, and system resources to run. It’s not going to be the ideal tool for everybody. And it works on Linux systems only (which pretty much excludes real-time projects anyway). But if you’re already a paid-up DS-5 user, it’s a free upgrade.

And how often do you get free time? 

One thought on “Bug-B-Gone!”

  1. I duuno. For me this is a bit like auto-correct in Word. In the end, you don’t know how to spell because Word is doing everything for you.
    This “undo” thing lets you write code that is effectively above your intellectual skills. I don’t think that’t a good idea in the long run.

    In my days all we had was printf and we liked it! Now get off my lawn…

Leave a Reply

featured blogs
Sep 28, 2022
Learn how our acquisition of FishTail Design Automation unifies end-to-end timing constraints generation and verification during the chip design process. The post Synopsys Acquires FishTail Design Automation, Unifying Constraints Handling for Enhanced Chip Design Process app...
Sep 28, 2022
You might think that hearing aids are a bit of a sleepy backwater. Indeed, the only time I can remember coming across them in my job at Cadence was at a CadenceLIVE Europe presentation that I never blogged about, or if I did, it was such a passing reference that Google cannot...
Sep 22, 2022
On Monday 26 September 2022, Earth and Jupiter will be only 365 million miles apart, which is around half of their worst-case separation....

featured video

PCIe Gen5 x16 Running on the Achronix VectorPath Accelerator Card

Sponsored by Achronix

In this demo, Achronix engineers show the VectorPath Accelerator Card successfully linking up to a PCIe Gen5 x16 host and write data to and read data from GDDR6 memory. The VectorPath accelerator card featuring the Speedster7t FPGA is one of the first FPGAs that can natively support this interface within its PCIe subsystem. Speedster7t FPGAs offer a revolutionary new architecture that Achronix developed to address the highest performance data acceleration challenges.

Click here for more information about the VectorPath Accelerator Card

featured paper

Algorithm Verification with FPGAs and ASICs

Sponsored by MathWorks

Developing new FPGA and ASIC designs involves implementing new algorithms, which presents challenges for verification for algorithm developers, hardware designers, and verification engineers. This eBook explores different aspects of hardware design verification and how you can use MATLAB and Simulink to reduce development effort and improve the quality of end products.

Click here to read more

featured chalk talk

EdgeLock® Secure Element & Secure Authenticator

Sponsored by Mouser Electronics and NXP Semiconductors

Today’s IoT designs demand comprehensive security implementation, but incorporating a robust security solution in your design can be a complicated and time-consuming process. In this episode of Chalk Talk, Amelia Dalton and Antje Schutz from NXP explore NXP’s EdgeLock Secure Element and Secure Authenticator Solution. They examine how this flexible, future-proof and easy to deploy solution can be a great fit for a variety of IoT designs.

Click here for more information about NXP Semiconductors EdgeLock® SE050 Plug & Trust Secure Element Family