Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Program Debugging in an Incompletely Assembled Runtime Environment

IP.com Disclosure Number: IPCOM000118693D
Original Publication Date: 1997-May-01
Included in the Prior Art Database: 2005-Apr-01
Document File: 4 page(s) / 136K

Publishing Venue

IBM

Related People

Pazel, DP: AUTHOR

Abstract

Disclosed is the principal components and methods for constructing a program error detection tool, herein referred to as a "virtual debugger". The virtual debugger allows testing of complex program units to be conducted prior to component or integrated testing and even prior to the component development completion. This is achieved through "non-sequenced program statement execution" in an incompletely assembled program runtime environment.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 44% of the total text.

Program Debugging in an Incompletely Assembled Runtime Environment

      Disclosed is the principal components and methods for
constructing a program error detection tool, herein referred to as a
"virtual debugger".  The virtual debugger allows testing of complex
program units to be conducted prior to component or integrated
testing and even prior to the component development completion.  This
is achieved  through "non-sequenced program statement execution" in
an incompletely  assembled program runtime environment.

      By non-sequenced program statement execution, it is meant that
the user is allowed to execute program statements in almost any
order, with no necessity to begin at the program's initial entry
point. This is  facilitated through a modification of the program's
runtime environment  in which it is not essential for all program
stack nor global and local  variable information to be instantiated.
It is in this sense that the  runtime is incompletely assembled.  It
is still essential that the runtime information be logically
consistent, as in having the calling sequences represented in the
stack reflect a true calling sequence, for  example, but it is not
necessarily complete.  The statement that is selected to execute
drives the assembly of the runtime.  Stack entries  are added and
deleted as necessary, for example.  Also, in the event that
insufficient information is available for statement execution,
requests are made for that information from the user by way of the
virtual debugger tool, thereby further assembling the runtime.

      The Figure depicts the components of the virtual debugger,
their relationships, and brings focus to the component composition of
the virtual program emulator.  The user-interface views provide user
information about the current state of the debugged program.  They
also provide a means for the user to enter commands textually or
graphically.  The user interface manager/input command processor both
manages the user interface (adjusts windows, colors, etc.) and
intercepts user input.  User input that affects the tool's
presentation or general  behavior is handled by this component.  The
user input that affects the  state of the debugged program is passed
to the virtual program emulator.

      The virtual execution services, a component of the virtual
program emulator, interprets commands from the user interface
manager/input command processor and specifies actions to the other
components in an attempt to execute the command.  The virtual
interpreter component is able to read and parse the program content.
The program content consists of program data in a format that the
interpreter is capable of reading and parsing.  The virtual
interpreter processes this  information and attempts to execute
program statements.  A further result  of this processing is the
construction of two data dictionaries namely  the global data
dictionary and the local data dictionar...