Machine independent debugger

Details Machine independent debugger Machine independent debugger

1999-12-30

2004-09-21

Ingberg, Todd (Department: 2124)

Data processing: software development, installation, and managem

Software program development tool

Testing or debugging

C717S124000, C717S127000

Reexamination Certificate

active

06795962

ABSTRACT:

FIELD OF THE INVENTION
This invention relates generally to source-code debuggers, and more particularly to the composition of symbol tables and management of breakpoints.
COPYRIGHT NOTICE/PERMISSION
A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever. The following notice applies to the software and data as described below and in the drawings hereto: Copyright © 1999, Microsoft Corporation, All Rights Reserved.
BACKGROUND OF THE INVENTION
Computer program debuggers are used by programmers to find problems that occur during the execution of a program. Debuggers can be used to control the execution of a program using breakpoints to stop execution of the program at desired points. This allows the programmer to examine variables and a call stack during execution in such a manner that the user of the debugger can view snapshots of the execution of a program and determine if the program is behaving as expected. Users of debuggers can also browse source files, set breakpoints, watch variables, and examine data structures.
Symbol tables, also known as debugging tables, are used by program debuggers to provide detailed information during the execution of the program. A symbol table is generated or emitted by the compiler and linker when the program source code is compiled and linked. Symbol tables are associated with a file that contains the generated executable code of the program. The symbol table maps source statements to byte addresses of executable instructions, which provide guidance in setting breakpoints and examining data during execution. More specifically, debugger symbol tables contain information describing the source code, such as line numbers, the types and scopes of variables, and function names, parameters, function scopes and name/attribute bindings specified by the declarations in a program. Debugger symbol tables also contain information describing the generated executable code. The symbol table enables the debuggers to map source-level variables and data structures to a specific location in the memory of the program being debugged. Debugger symbol tables are not the same as a symbol table that is used internally by the compiler during compilation.
Conventionally, debuggers have been considered notoriously machine-dependent programs. Many conventional debuggers, such as the GNU debugger, gdb, described in R. M. Stallman and R. H. Pesch, ‘Using GDB: A guide to the GNU source-level debugger, GDB version 4.0
’, Technical Report
, Free Software Foundation, Cambridge, Mass., Jul. 1991, do indeed depend heavily on a specific operating system or on a specific platform or compiler. In conventional debuggers, symbol tables are encoded ad-hoc, in which the information in the symbol table is machine-dependent, in which at least a portion of the information in the symbol table is unique to, or characteristic of, a particular computer environment. More specifically, the machine-dependence pertains to machine architectures, operating systems, compilers, and linkers, in which specific or unique features of the computer environment that cannot be easily used, if at all, in a different environment. Beyond the direct consequence of a lack of portability of the symbol table between platforms, a machine-dependent ad-hoc symbol table also has the consequence of the debugger being machine-dependent because the debugger must have the ability to parse and process the machine-dependent information in the symbol table, which in turn requires that the debugger be revised or at least be re-compiled for each specific computer type. While most debuggers are notoriously machine-dependent, recent research prototypes have achieved varying degrees of machine-independence with novel designs, such as by embedding symbol tables and debugging code in the target program. However, embedding symbol tables and debugging code in the target program results in relatively slow execution and a larger symbol table.
Two nearly machine-independent debuggers, ldb and cdb, are source-level debuggers for C. However, neither ldb nor cdb are completely machine independent. Ldb is described in N. Ramsey and D. R. Hanson, ‘A retargetable debugger’,
Proceedings of the SIGPLAN '
92
Conference on Programming Language Design and Implementation, SIGPLAN Notices
, 27(7), 22-31 (1992). Ldb is easier to port to a different architecture, but it uses its own symbol-table format and thus requires cooperation from compilers. Cdb is described in D. R. Hanson and M. Raghavachari, ‘A machine-independent debugger’,
Software
-
Practice and Experience,
26(11), 1277-1299 (1996). Cdb explores perhaps the extreme reaches of this design space: It is nearly completely independent of architectures and operating systems, but it achieves this independence by loading a small amount of code with the target program and by having the compiler emit a non-standard, but machine-independent, symbol table. Furthermore, cdb embeds symbol tables and debugging code in the target program. Cdb does illustrate how focusing on retargetability can simplify a debugger dramatically.
Furthermore, conventional symbol tables are designed as file formats and symbol tables are documented in torturously detailed specifications. Symbol table file formats are also difficult to change. For example, conventional debuggers can set breakpoints only on discrete lines of code, because the symbol-table format provides information only about lines even though the syntax of most languages is not line-oriented and includes operations that have embedded flow of control. Java's class files are described as a file format, and class files include metadata that map locations to line numbers as described in T. Lindholm and F. Yellin,
The Java Virtual Machine Specification
, Addison Wesley, Reading, Mass., 1997.
FIG. 1
shows a diagram of a debugger nub
110
in a conventional scheme. A nub
110
is the central feature of conventional designs. The nub
110
enables a debugger
130
to debug a target program
120
that is being debugged and that is running on the same computer or another computer as the nub
110
. The nub
110
is a small program that controls the target program
120
, and is responsible for actions such as setting breakpoints and stepping through code. The nub
110
provides a layer between the main debugger application
130
and the low level system operations. The nub
110
also provides debugging primitives. The nub
110
provides facilities for communicating with the debugger
130
and controlling the target
120
. Low-level operations of the debugger
130
are performed by communicating with the nub
110
which is a small set of machine-dependent functions that are embedded in the target program
120
at compile-time.
As depicted in
FIG. 1
, all communication between the target program
120
and the debugger
130
goes through the nub
110
. The nub
110
is a program loaded into memory with the target program
120
. The debugger
130
can be either in the same memory address space as the target program
120
, or in a separate memory address space. The latter configuration is a common one, because it protects the debugger
130
from corruption by the target program
120
. Furthermore, the debugger
130
and the target program
120
can execute in the same computer in which the debugger
130
and the target program
120
communicate through a system bus. The debugger
130
and the target program
120
can also execute in different computers in which the debugger
130
and the target program
120
communicate through a relatively slow communication link, such as a Remote Procedure Call (RPC) channel.
Furthermore, in a conventional debugger
130
, the management of user breakpoint information is performed by the debugger
130
. In implementations w

Affiliated with

Also associated with

Rating

Machine independent debugger does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Machine independent debugger, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Machine independent debugger will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3231699