Browse Prior Art Database

Design for an Execution Control System for a Linux Application Debugger Disclosure Number: IPCOM000021210D
Original Publication Date: 2004-Jan-02
Included in the Prior Art Database: 2004-Jan-02
Document File: 2 page(s) / 14K

Publishing Venue



This article describes a method for designing a full-function, C/C++ application debugger without using GDB (GNU Project Debugger) or any other GPL executables.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 2

Design for an Execution Control System for a Linux Application Debugger

To create the Linux application debugger, the Interactive Code Analysis Tool (ICAT) debugger previously developed for Windows and OS/2 systems was modified. ICAT consists of a graphical user interface (GUI), a debugger engine (DE), and a debugger probe (DP). The GUI accepts user requests, reflects the current state of the debugged application, and interfaces with the DE. The DE processes the user requests, performs expression analysis, updates the state information of the debugged application, and interfaces with the DP. The DP instruments the debugged application and interacts with the operating system to provide the debugging function.

For cases in which the user wishes to debug an application on a remote system, some of the DE function is split off into a separate daemon, which runs on the target system of interest along with the DP. The remainder of ICAT runs on the host system and communicates with the daemon, typically via TCP/IP.

The core function of any debugger is to control the execution of the application under test. The user may either single step the application code one line at a time or run the application until some event occurs. The DE must supervise this execution until the single step is completed or the event of interest occurs. Events of interest include breakpoints, module load notifications, and any exceptions that should be reported to the user.

Linux System Resources for Debugging

An application debugger for Linux controls an application via the PTRACE system call. PTRACE allows a debugger to launch an application for debugging, attach to a process already executing, read and write data, read and write registers, step a thread, and execute a thread.

The use of the PTRACE call is relatively straightforward if the application being debugged is single-threaded. When an application becomes multi-threaded, the DE still uses PTRACE to control execution, but ICAT's execution control becomes much more complicated:

A debugger must set breakpoints in system library code in order to detect certain conditions. A debugger must read and write certain operating system data areas. Anytime a thread stops for any reason, the other threads are explicitly stopped. The order in which threads are restarted is important. Certain special signals are received from stopping threads. The order in which threads are restarted is affected by the receipt of special signals. When an application first spawns a secondary thread, a manager thread is created. The manager thread never executes user code, but it must be controlled by the debugger.

Linux has a "proc" area that contains a great deal of information about processes that are currently executing on the system. The proc area can be read using the various system functions for reading fil...