Browse Prior Art Database

Parallel Execution Thread for Trace Support within a Debugger

IP.com Disclosure Number: IPCOM000105753D
Original Publication Date: 1993-Sep-01
Included in the Prior Art Database: 2005-Mar-20
Document File: 2 page(s) / 75K

Publishing Venue

IBM

Related People

Lindsey, AH: AUTHOR

Abstract

When debugging any form of source code, it is imperative to be able to study in detail logic flow and data movement. One common technique for satisfying this need is the use of trace output that provides details about the operations that are occurring to support execution. Examples of the types of information that are presented include:

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

Parallel Execution Thread for Trace Support within a Debugger

      When debugging any form of source code, it is imperative to be
able to study in detail logic flow and data movement.  One common
technique for satisfying this need is the use of trace output that
provides details about the operations that are occurring to support
execution.  Examples of the types of information that are presented
include:

o   Messages
o   Data values (before and after operations)
o   Database and file I/O operations
o   Logic flow
o   Results of conditional evaluations
o   Source statements

      Unfortunately, the ability to support such trace information
likely impacts the performance and maintainability of the debugging
tool that provides the support.  This is because the typical
technique for solving this problem is to check whether or not to
generate trace output everywhere within the debugger that trace
information can be produced.  This results in a large number of
redundant checks, which negatively affects performance, and a wide
distribution of these checks, which reduces maintainability (for
example, the criteria for when to trace may change).

      When providing trace output support, it is desirable to
maintain good performance within the system, especially such that
execution WITHOUT tracing is not negatively affected.  This is needed
since collecting trace output is just one form of debugging which may
not be used for more simple problems.

      Likewise, it is also desirable to keep the code checks that
determine if trace output should be generated localized to one place
within the product.  This has two major benefits.  First, when the
need arises to alter the conditions under which tracing should occur,
such as the ability to place a condition on tracing, only one portion
of code need be altered.  If the interface to the tracing check has
not changed, this can be achieved using other techniques if the check
is isolated within a function call.  However, if the interface DOES
change, then t...