Browse Prior Art Database

Method For Enhancing Performance Of Hardware Assisted Breakpoints Across Multiple Modules Through The Use Of A "Module Return" hook.

IP.com Disclosure Number: IPCOM000098007D
Original Publication Date: 2005-Mar-07
Included in the Prior Art Database: 2005-Mar-07
Document File: 2 page(s) / 58K

Publishing Venue

IBM

Abstract

This disclosure describes a method by which a debugger can be made to run more efficiently by controlling the state (active or deferred) of hardware assisted breakpoints.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 46% of the total text.

Page 1 of 2

Method For Enhancing Performance Of Hardware Assisted Breakpoints Across Multiple Modules Through The Use Of A "Module Return" hook.

Application debuggers can use hardware facilities (Program Event Recorder (PER) on IBM z/Series) to handle location breakpoints. A location breakpoint is any that can be resolved to an address such as address, line or function breakpoints. For debuggers using PER, multiple location breakpoints can often hinder debugger performance while running. This is because a single PER bracket (or address range) is set which contains all location breakpoints. i.e. The beginning address of the PER bracket is the address of the location breakpoint with the lowest address. The ending address of the PER bracket is the address of the location breakpoint with the highest address. This indicates that just two location breakpoints have the potential of creating a large PER bracket which can cause a debugger to run less efficiently. Consider an application consisting of more than one module, where a module is a linked group of compiled objects. These modules can occupy very different address areas. So a breakpoint set in each module can create a large PER bracket. A debugger can use the concept of deferred breakpoints. Such breakpoints are those which are known to the debugger but are not active to the debugger at a given point in an application flow. This disclosure describes a method by which the state (active or deferred) of location breakpoints are automatically controlled so that only location breakpoints in the module which is currently executing are active. The method handles both the run mode of a debugger and the single-step mode of a debugger. The method uses software hooks in intra-module linkage code and implicit (unobserved to the user) module switch breakpoints to control the state of location breakpoints. Again, only active location breakpoints effect the PER bracket. The software hooks in the intra-module linkage code will trap all entrances into all modules, by call and by return. And an implicit module switch breakpoint is set for any module for which a user set location breakpoints exists. This implicit module switch breakpoint is used internally by the debugger to set the state of location breakpoints and to adjust the PER bracket. Example Scenario:

The following uses two location breakpoints in different modules to describe how the software hooks and implicit breakpoints manage the state of location breakpoints. In this scenario, module A calls B which calls C, and then returns back through the chain to A. The debugger user sets one location breakpoints in module B and one in module C.

A -> B -> C

1) Setting location breakpoints while in module A

Assume the debug session currently has control in module A. When the users set a location breakpoint in module B, an implicit module switch breakpoint is for module B. That implicit module switch breakpoint is relevant to module B entrance by call from A and...