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

General Debug Tool for Problem Determination

IP.com Disclosure Number: IPCOM000116418D
Original Publication Date: 1995-Sep-01
Included in the Prior Art Database: 2005-Mar-30
Document File: 2 page(s) / 81K

Publishing Venue

IBM

Related People

Anand, VK: AUTHOR [+2]

Abstract

Each software product usually builds its own specific trace and debug tools to help in problem determination. One important and yet general tool that would help most of the software subsystems would be a structural interpreter of its data segment(s) from memory dump. Many communication or database subsystems or operating systems do have tools to dump their data segments or memory and to format the data. These tools use the structures defined by the subsystem to format the dump. Hence, the tools may use the same structure files as its include files. Whenever the structures are changed the tools need to be rebuilt. One example would be LAPSDUMP used for Lan Adapter and Protocol Support (LAPS).

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

General Debug Tool for Problem Determination

      Each software product usually builds its own specific trace and
debug tools to help in problem determination.  One important and yet
general tool that would help most of the software subsystems would be
a structural interpreter of its data segment(s) from memory dump.
Many communication or database subsystems or operating systems do
have tools to dump their data segments or memory and to format the
data.  These tools use the structures defined by the subsystem to
format the dump.  Hence, the tools may use the same structure files
as its include files.  Whenever the structures are changed the tools
need to be rebuilt.  One example would be LAPSDUMP used for Lan
Adapter and Protocol Support (LAPS).  Every change to the protocol
stack that affects the data structures of the protocol driver affects
the tool LAPSDUMP, so LAPSDUMP needs to be changed and rebuilt.  As a
result, there are multiple versions of LAPSDUMP along with multiple
levels or releases of LAPS.  The user should make sure that the level
of LAPS and LAPSDUMP match on his or her system.  The problem
determination with these kind of tools frustrate the users if they
are not aware of the different levels.  Moreover, modifying these
tools involves time.  To reduce cost, it might be necessary to
redesign these tools aiming at general solutions by making them
insensitive to changes made to the software product.  This article
looks at how these tools can be designed to overcome the above
mentioned problem.

      Tools should be built as generic as possible.  All the specific
information of a product should be isolated and the tool should
receive
the product specific information through another DEFINED interface.

      If any product wants to use this general debug tool, the
product should follow a defined convention in declaring data
structures.
This defined convention spec should be made available along with the
tool.  Any software application or subsystem that chooses to use this
tool for problem determination, should follow the tool's
specification.
For example, some of the rules may be specified as follows:
  1.  All global declarations should be at the beginning of their
data
       segments.
  2.  All the head pointer of queue and the starting address of the
       arrays or link lis...