HARDWARE SUPPORT FOR SOFTWARE DEBUGGING IS CRITICAL. HARDWARE SUPPORT IS NECESSARY TO OBSERVE AND CAPTURE, WITH LITTLE OR NO OVERHEAD, THE EXACT EXECUTION OF A PROGRAM. PROVIDING THIS ABILITY TO DEVELOPERS WILL ALLOW THEM TO DETERMINISTICALLY REPLAY AND

Debugging software is challenging because of the increasing complexity of software and hardware, and the diversity of operating systems in use today. These factors make it difficult for software companies to reproduce and fix bugs that occur in released code, especially nondeterministic bugs that occur at a customer site. What makes matters worse is the increase in bugs because of the commercial pressure to release software early, aided and abetted by the ease of delivering software patches over the Internet. Tracking down and fixing these bugs can be a nightmare, costing a significant amount of time and money. These software bugs account for nearly 40 percent of computer system failures 1 and cost the US economy an estimated $59.5 billion annually. 2 A difficult part of debugging is reproducing the bugs that occur at a customer’s site. Most current debugging systems rely on core dumps, 3,4 which contain the final state of the system before the crash. Unfortunately, this solution is woefully inadequate because it is difficult to determine the cause of the error responsible for the core dump, and it provides little help in reproducing the bug. To assist developers, we propose the BugNet architecture to continuously record a program’s execution as it runs. 5 The information collected right before a program crash can help deterministically replay the last second of execution preceding the crash. Deterministic replay debugging (DRD) is the ability to replay the exact same sequence of instructions that led up to the crash; it is an effective technique for isolating the bug’s source. For the programs we have examined, capturing the last second of execution before the crash was sufficiently long enough to debug the root cause of the crash