The Design of a Debugger Unit for a RISC Processor Core

Recently, there has been a significant increase in design complexity for Embedded Systems often referred to as Hardware Software Co-Design. Complexity in design is due to both hardware and firmware closely coupled together in-order to achieve features for low power, high performance and low area. Due to these demands, embedded systems consist of multiple interconnected hardware IPs with complex firmware algorithms running on the device. Often such designs are available in bare-metal form, i.e without an Operating System, which results in difficulty while debugging due to lack of insight into the system. As a result, development cycle and time to market are increased. One of the major challenges for bare-metal design is to capture internal data required during debugging or testing in the post silicon validation stage effectively and efficiently. Post-silicon validation can be performed by leveraging on different technologies such as hardware software co-verification using hardware accelerators, FPGA emulation, logic analyzers, and so on which reduces the complete development cycle time. This requires the hardware to be instrumented with certain features which support debugging capabilities. As there is no standard for debugging capabilities and debugging infrastructure, it completely depends on the manufacturer to manufacturer or designer to designer. This work aims to implement minimum required features for debugging a bare-metal core by instrumenting the hardware compatible for debugging. It takes into consideration the fact that for a single core bare-metal embedded systems silicon area is also a constraint and there must be a trade-off between debugging capabilities which can be implemented in hardware and portions handled in software. The paper discusses various debugging approaches developed and implemented on various processor platforms and implements a new debugging infrastructure by instrumenting the Open-source AMBER 25 core with a set of debug features such as breakpoints, current state read, trace and memory access. Interface between hardware system and host system is designed using a JTAG standard TAP controller. The resulting design can be used in debugging and testing during post silicon verification and validation stages. The design is synthesized using Synopsys Design Compiler targeting a 65 nm technology node and results are compared for the instrumented and non-instrumented system

Debugging real-time software in a host-target environment

A common paradigm for the development of process-control or embedded computer software is to do most of the implementation and testing on a large host computer, then retarget the code for final checkout and production execution on the target machine. The host machine is usually large and provides a variety of program development tools, while the target may be a small, bare machine. A difficulty with the paradigm arises when the software developed has real-time constraints and is composed of multiple communicating processes. If a test execution on the target fails, it may be exceptionally tedious to determine the cause of the failure. Host machine debuggers cannot normally be applied, because the same program processing the same data will frequently exhibit different behavior on the host. Differences in processor speed, scheduling algorithm, and the like, account for the disparity. This paper proposes a partial solution to this problem, in which the errant execution reconstructed and made amenable to source language level debugging on the host. The solution involves the integrated application of a static concurrency analyzer, an interactive interpreter, and a graphical program visualization aid. Though generally applicable, the solution is described here in the context of multi-tasked real-time Ada* programs

Easier Debugging of Multithreaded Software

Software activation is a technique designed to avoid illegal use of a licensed software. This is achieved by having a legitimate user enter a software activation key to validate the purchase of the software. Generally, a software is a single-threaded program. From an attacker’s perspective, who does not wish to pay for this software, it is not hard to reverse engineer such a single threaded program and trace its path of execution. With tools such as OllyDbg, the attacker can look into the disassembled code of this software and find out where the verification logic is being performed and then patch it to skip the verification altogether. In order to make the attacker’s task difficult, a multi-threaded approach towards software development was proposed [1]. According to this approach, you should break the verification logic into several pieces, each of which should run in a separate thread. Any debugger, such as OllyDbg, is capable of single-stepping through only one thread at a time, although it is aware of the existence of other threads. This makes it difficult for an attacker to trace the verification logic. Not just for an attacker, it is also difficult for any ethical developer to debug a multithreaded program. The motivation behind this project is to develop the prototype of a debugger that will make it easer to trace the execution path of a multi-threaded program. The intended debugger has to be able to single-step through all of the threads in lockstep

A Monitoring Language for Run Time and Post-Mortem Behavior Analysis and Visualization

UFO is a new implementation of FORMAN, a declarative monitoring language, in which rules are compiled into execution monitors that run on a virtual machine supported by the Alamo monitor architecture.Comment: In M. Ronsse, K. De Bosschere (eds), proceedings of the Fifth International Workshop on Automated Debugging (AADEBUG 2003), September 2003, Ghent. cs.SE/030902

Bug propagation and debugging in asymmetric software structures

Software dependence networks are shown to be scale-free and asymmetric. We then study how software components are affected by the failure of one of them, and the inverse problem of locating the faulty component. Software at all levels is fragile with respect to the failure of a random single component. Locating a faulty component is easy if the failures only affect their nearest neighbors, while it is hard if the failures propagate further.Comment: 4 pages, 4 figure

Mining Sequences of Developer Interactions in Visual Studio for Usage Smells

In this paper, we present a semi-automatic approach for mining a large-scale dataset of IDE interactions to extract usage smells, i.e., inefficient IDE usage patterns exhibited by developers in the field. The approach outlined in this paper first mines frequent IDE usage patterns, filtered via a set of thresholds and by the authors, that are subsequently supported (or disputed) using a developer survey, in order to form usage smells. In contrast with conventional mining of IDE usage data, our approach identifies time-ordered sequences of developer actions that are exhibited by many developers in the field. This pattern mining workflow is resilient to the ample noise present in IDE datasets due to the mix of actions and events that these datasets typically contain. We identify usage patterns and smells that contribute to the understanding of the usability of Visual Studio for debugging, code search, and active file navigation, and, more broadly, to the understanding of developer behavior during these software development activities. Among our findings is the discovery that developers are reluctant to use conditional breakpoints when debugging, due to perceived IDE performance problems as well as due to the lack of error checking in specifying the conditional