Browse Prior Art Database

Self-managed runtime plugin-able routines Disclosure Number: IPCOM000131147D
Original Publication Date: 2005-Nov-08
Included in the Prior Art Database: 2005-Nov-08
Document File: 2 page(s) / 68K

Publishing Venue



The purpose of this invention is to design a mechanism where multiple routines that perform similar tasks can be registered into a central repository, and the user can call a single API to perform the task rather than calling the individual routines serially. It has the following advantages: - The function prototype for each routine is always the same. The parameters are communicated through objects (i.e. structures/class objects). - The actual routine that perform the task only needs to be setup once, and any future user-defined routines can be added into the repository without adding further setup codes.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 54% of the total text.

Page 1 of 2

Self-managed runtime plugin-able routines

Most debuggers can only understand one type of debug information format. (i.e. DWARF format). An application containing foreign debug information can not be processed by these debuggers unless the debug information is first converted to a debug format that the debugger understands. The process of converting from one debug format to another can be encapsulated in a single routine. Given such a conversion routine, a debugger can take advantage of it by invoking the conversion routine when certain conditions are met (i.e. when it detects foreign debug information).

For each new conversion routine, the debugger wishes to support, it needs additional logic to determine when and where to invoke the conversion routine. It is not necessarily obvious where the best place is to add this additional logic. The purpose of this invention is to design a set of APIs to encapsulate this information, so a debugger would only need to register the conversion routine with the API once, and the APIs would do the rest of the work. This approach is less error prone, and it allows the debugger to choose which conversion routines to support at runtime.

These APIs can be applied to other areas within the debugger as well. For example, stackframe traversal is different on various platforms. For a debugger to be able to debug applications on various platforms, it must have knowledge of the different stackframe traversal routines. In order to make use of these routines, the debugger can register them to the APIs, and call the main traversal routine to perform the stackframe traversal.

This set of APIs can also be applied to other applications as well. For example, a banking application dealing with currency exchange can use this set of APIs to register a new currency exchange routine. The main currency exchange routine can be reused to invoke the new routine.

Detail of invention:

The layout of the data structure will first be described, and a small example will follow.

The basic layout of the data structures (these are to be provided by the API provider)

"Task Routine" object:

The purpose of this object is to store the list of routines that can perform the task.




The routines must conform to a strict function prototype, and it must accept a "Task Requirement"

object as parameter.

Each routine in this list must communicate through return code to indicate if it has successfully

been completed.

"Task Requirement" object:

The purpose of this object is to gather all the necessary information that are necessary to perform

a task. (i.e. input parameters)

It must also have fields to record the outcome of a task. (i.e. return parameters)

Each "Task Requirement" object must contain exactly one "Task Routine" object. The "Task

    Routine" object contains all the routines that can be applied on each "Task Requirement" objec...