Browse Prior Art Database

Method of setting a plurality of debugger function breakpoints using a wildcards

IP.com Disclosure Number: IPCOM000021961D
Original Publication Date: 2004-Feb-17
Included in the Prior Art Database: 2004-Feb-17
Document File: 3 page(s) / 61K

Publishing Venue

IBM

Abstract

The invention provides a method of using a wildcard character, '*', when setting function breakpoints in a debugger. Setting a function breakpoint is a request to a debugger to stop execution of an application being debugged when a specific application function is executed. When a debugger user desires to set a function breakpoint, they must identify to the debugger, the location and name of the application function on which to set the breakpoint. The invention allows the user to use a wildcard character in the application module and application object names (i.e. location) and function name. An application module is a linked grouping of application objects. An application object is a machine executable file.

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 53% of the total text.

Page 1 of 3

Method of setting a plurality of debugger function breakpoints using a wildcards

The use of wildcards is explained here. Location Wilcards) Allowing a wildcard character in the application module name and object name allows a user to selectivey identify multiple locations in an applcation to set a function breakpoint. This may be useful if the location of the function to be debugged is not know by the user. For example, if a debugger user does not know in what module a function is in or in what object in a module a function is in, the user can make use of the wildcard feature to set the function breakpoint. Assume an application has; Mod1, Mod2, Mod3 and each has several Objects Module: Mod*
Object: Obj*
Function: MyFunction
The debugger will stop application execution when the MyFunction is entered.

    Function Name Wildcard) Allowing a wildcard in the function name allows for setting of multiple function breakpoints via one set action by the debugger user. For example, if a application module has ten functions named similiarly: MyFunction1 thru MyFunction10. The invention allows the debugger user to set a SINGLE function breakpoint as follows;

Module: Module1 Object: Object1 Function: MyFunc* The debugger will stop application execution each time any of MyFunctions1-10 is entered.

    Wildcards can be used in module name, object name and function name at the same time as well.

Module: * Object: * Function: * In this case the debugger will stop at all functions in the application.

    The wildcard solution internally creates and maintains a linked list of "explicit" and a linked list of "implicit" breakpoints. Explicit breakpoints are those entered by the debugger user and will be viewable/maintanable by the user. Implicit breakpoints are of two types, function and load occurrence, and are hidden to the user. A load occurrence breakpoint is used to alert the debugger that the applcation has entered and new module. The invention uses the load occurrence breakpoints to create implicit function breakpoints upon load module entry. Pointers are maintained between the explicit and implicit breakpoints to allow coordination.

    The following diagrams are intended to illustrate explicit and implicit function breakpoints as used by the invention; their relationships and existance.

Assume an a...