US20070174703A1 - Method for enhancing debugger performance of hardware assisted breakpoints - Google Patents

Method for enhancing debugger performance of hardware assisted breakpoints Download PDF

Info

Publication number
US20070174703A1
US20070174703A1 US11/330,452 US33045206A US2007174703A1 US 20070174703 A1 US20070174703 A1 US 20070174703A1 US 33045206 A US33045206 A US 33045206A US 2007174703 A1 US2007174703 A1 US 2007174703A1
Authority
US
United States
Prior art keywords
breakpoints
location
debugger
units
valid
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
US11/330,452
Other versions
US8108840B2 (en
Inventor
Daniel Gritter
Gerald Strait
Mei-Hui Wang
Joshua Wisniewski
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Priority to US11/330,452 priority Critical patent/US8108840B2/en
Assigned to INTERNATIONAL BUSINESS MACHINES CORPORATION reassignment INTERNATIONAL BUSINESS MACHINES CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: WISNIEWSKI, JOSHUA B., GRITTER, DANIEL S., STRAIT, GERALD B., WANG, MEI-HUI
Publication of US20070174703A1 publication Critical patent/US20070174703A1/en
Application granted granted Critical
Publication of US8108840B2 publication Critical patent/US8108840B2/en
Expired - Fee Related legal-status Critical Current
Adjusted expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/362Software debugging

Definitions

  • the present invention relates generally to code debugging in computer systems and, more particularly, to a method for enhancing debugger performance of hardware assisted breakpoints.
  • debugger During development of application programs, developers use a debug program (debugger) to control the flow of application program execution and to inspect aspects of programs.
  • the debugger allows developers to set breakpoints at specific locations in an application module so that the programmer can step into the code line-by-line, or resume execution of the program as required. Breakpoints corresponding to an address (termed “location breakpoints”) are resolved with assist from a hardware event facility. When an instruction is fetched from an address range being monitored by a hardware event facility, the facility will notify the debugger and the debugger will stop an application and display the location.
  • Debugger location breakpoints that represent respective addresses are used to create the hardware event facility address range. Debuggers may also use breakpoints that are not hardware assisted.
  • the hardware event facility maintains a single address range. That is, if a first location breakpoint is set for address 1000 in the system memory and a second location breakpoint is set for address 2000 , then a range is set with a begin address of 1000 and an end address of 2000 . Thus, all addresses between (and including) 1000 and 2000 are monitored. Where the begin and end addresses defining a range are far apart from one another, then the hardware event facility is forced to monitor a large address range, which takes more time than monitoring a small address range. As a result, a debugger with active location breakpoints representing a large address range becomes noticeably less efficient. Value would be therefore be added to a debugger if the maximum address range monitored by a hardware event facility could be kept to a minimum.
  • the validation process typically ensures that the information provided by the user represents a real program address. If the location breakpoint can be validated then it is set as active, thus affecting the hardware event facility address range. On the other hand, if the breakpoint cannot be validated, the debugger will not allow it to be set.
  • debuggers may also provide an option in which a deferred breakpoint may be created; that is, a “deferred” breakpoint is one that is validated at a later time.
  • deferred location breakpoints do not affect the hardware event facility address range prior to validation thereof.
  • deferred breakpoints are validated as additional application modules are entered. If a deferred location breakpoint can be validated at such a time, then its state is changed from “deferred” to “active” and it will result in redefining the hardware event facility address range if it falls outside the existing range. If it cannot be validated, the breakpoint remains in a deferred state.
  • the method includes deferring all active location breakpoints within the multiple program units, and subsequently activating each valid location breakpoint in a present one of the multiple program units being entered.
  • a storage medium includes a machine readable computer program code for enhancing debugger performance of hardware assisted breakpoints across multiple program units, and instructions for causing a computer to implement a method.
  • the method further includes deferring all active location breakpoints within the multiple program units, and subsequently activating each valid location breakpoint in a present one of the multiple program units being entered.
  • a computer architecture includes a hardware event facility for monitoring a debugging process of application programming units stored in memory, and a linkage code for executing calls and returns between the application programming units, the linkage code further including a debugger hook handler therein.
  • the debugger hook handler is configured for, upon activation thereof, deferring all active location breakpoints within the application programming units and subsequently activating each valid location breakpoint in a present one of the application programming units being entered.
  • FIG. 1 illustrates a general-purpose computing environment suitable for use in accordance with an embodiment of the invention
  • FIG. 2 schematically illustrates an application made up of a number of modules, each containing objects that in turn contain functions, and the module linkage code executed during a call or return between functions in different modules;
  • FIG. 3 schematically illustrates module linkage code configured with a debugger hook handler, in accordance with an embodiment of the invention
  • FIG. 4 is a flow diagram illustrating a method for enhancing debugger performance of hardware assisted breakpoints across multiple program units, in accordance with an embodiment of the invention
  • FIG. 5 ( a ) is an application sequence flow diagram for a series of hypothetical call/return operations executed between a plurality of modules having location breakpoints included therein;
  • FIG. 5 ( b ) is a table illustrating a comparison between the resulting address range at various locations in a debugging sequence with and without the use of the methodology shown in FIG. 4 .
  • Disclosed herein is a method for enhancing debugger performance of hardware assisted breakpoints across multiple program units, such as modules.
  • the state of debugger location breakpoints in a debug session are controlled in a manner such that only the breakpoints for an application module which is currently executing are in an active state, while all others are deferred until such time as their respective units (modules) are entered/re-entered.
  • the effective address range of a hardware event facility is minimized, thereby improving the performance of a debugger.
  • a “program unit” generally refers to a unit of application code with defined entry and exit code to which a debugger hook can be added. Examples of this include functions and modules in the C programming language. That is, all functions in a C program include function linkage code which executes when the function is entered and exited. Similarly, a call to or return to a function in a different program module will execute module linkage code to which a debugger hook can be added.
  • the methodology described herein may be implemented through hooks in module linkage code, but can also be applied to similar linkage code such as function linkage. It should therefore be understood that present methodology is not necessarily limited to the scope of module linkage.
  • the method can be applied to any program unit which includes entry and exit code to which a call hook handler can be included.
  • the common concept of a function includes entry and exit linkage code.
  • the computer architecture 100 includes a central processing unit (CPU) 102 , as well as operating system code 104 , supporting environment code 106 and application code 108 (the code residing in memory 110 where they may execute).
  • Program developers create application programs by writing source code and compiling source into objects and linking objects into modules and loading those modules to the memory 110 of the computer.
  • the architecture 100 also includes a hardware event facility 112 that assists in the debugging process.
  • FIG. 2 schematically illustrates an application made up of a number of modules 202 (Module A, Module B) each containing objects 204 that in turn contain functions 206 .
  • Functions are discrete blocks of code which are callable, perform a task and return to their caller. Whenever a function calls to (or returns to) a function in a different module, common environment linkage code 208 will execute as part of the call or return. In conventional debugging techniques, breakpoints that are active in Module A, for example, will remain so even after a call to another function in Module B, which can possibly result in the creation of a larger than necessary address range during the execution of a function in Module B.
  • FIG. 3 schematically illustrates module linkage code 300 that is configured with a debugger hook handler 302 , in accordance with an embodiment of the invention.
  • the module linkage code 300 and the debugger hook handler 302 execute when a function calls to or returns to a function in a different module. It will be noted that the debugger hook handler only executes if the application is being debugged.
  • An exemplary methodology 400 implemented by the debugger hook handler 302 (and called from the module linkage code 300 ) is illustrated in the flow diagram of FIG. 4 .
  • the process 400 begins with the execution of the debugger hook handler upon being called from the module linkage code, as shown at block 402 .
  • the linkage code 300 and thus debugger hook handler 302 are called either during a function call or a return.
  • the process flow 400 can depict either situation.
  • all active location breakpoints in the application are set to a deferred state, as shown at block 404 .
  • decision block 406 it is determined whether there are any location breakpoints included in the module currently being entered. If not, then the process simply returns back to the module linkage code as shown at block 408 .
  • process 400 proceeds to decision block 410 to determine whether a first location breakpoint in the module being entered is valid (e.g., represents a real program address). If so, then the state of the location breakpoint is changed from deferred to active, as shown in block 412 ; if not, the location breakpoint is not made active. In either instance, the process 400 then reaches decision block 414 to determine whether other location breakpoints are present in the module being entered. If so, the process 400 loops back to decision block 410 and continues until all valid location breakpoints in the module being entered have been changed from deferred to active. Then, the debugger hook handler routine is completed and the process returns back to the module linkage code (block 408 ). Thus executed, the hook handler process activates deferred location breakpoints in the module being entered prior to module entry.
  • a first location breakpoint in the module being entered is valid (e.g., represents a real program address). If so, then the state of the location breakpoint is changed from deferred to active, as shown in
  • FIGS. 5 ( a ) and 5 ( b ) demonstrate an exemplary operation of the debugger hook handler for a sequence of call and return operations.
  • FIG. 5 ( a ) is an application sequence flow diagram for a series of hypothetical call/return operations executed between a plurality of modules (A, B, C) having location breakpoints included therein.
  • FIG. 5 ( b ) is a table illustrating a comparison between the resulting address range after each location in the sequence with and without the use of the above described hook handler methodology.
  • a first module has a begin address ( 5000 ) and an end address ( 6000 ) with location breakpoints at addresses 5500 and 5600 .
  • a second module has a begin address ( 1000 ) and an end address ( 2000 ) with location breakpoints at addresses 1500 and 1700
  • a third module has a begin address ( 80000 ) and an end address ( 85000 ) with location breakpoints at addresses 80500 and 80600 .
  • FIG. 5 ( b ) is a table that illustrates the difference in resulting address ranges between a conventional debugging sequence and the methodology illustrated in FIG. 4 .
  • the conventional results are depicted by the designation “without” while the results using the present methodology are depicted by the designation “with.”
  • the program has just begun and active location breakpoints are set in module A, while deferred location breakpoints are set in module B and C. The remaining numbered locations represent subsequent locations in the flow of a program.
  • the address range is from address 5500 to 5600 (i.e., 100 bytes). This is the case regardless of whether or not the present methodology is implemented.
  • location 2 there is a call from module A to module B.
  • the location breakpoints in module A remain active; thus, upon entering module B the activated location breakpoints therein result in an expanded address range of 4100 total bytes being monitored by the hardware event facility (now from 1500 to 5600 ).
  • the address range of activated location breakpoints is only 200 bytes in size (from 1500 to 1700 ).
  • location 3 upon return to module A, (location 3 ) the address range remains at 4100 bytes in a conventional process whereas the address range returns to 100 bytes in the present process (from 5500 to 5600 ).
  • the present method embodiments may therefore take the form of computer or controller implemented processes and apparatuses for practicing those processes.
  • the disclosure can also be embodied in the form of computer program code containing instructions embodied in tangible media, such as floppy diskettes, CD-ROMs, hard drives, or any other computer-readable storage medium, wherein, when the computer program code is loaded into and executed by a computer or controller, the computer becomes an apparatus for practicing the invention.
  • the disclosure may also be embodied in the form of computer program code or signal, for example, whether stored in a storage medium, loaded into and/or executed by a computer or controller, or transmitted over some transmission medium, such as over electrical wiring or cabling, through fiber optics, or via electromagnetic radiation, wherein, when the computer program code is loaded into and executed by a computer, the computer becomes an apparatus for practicing the invention.
  • the computer program code segments configure the microprocessor to create specific logic circuits.
  • a technical effect of the executable instructions is to implement the exemplary method described above and illustrated in FIG. 4 .

Abstract

A method for enhancing debugger performance of hardware assisted breakpoints across multiple units includes deferring all active location breakpoints within the multiple modules, and subsequently activating each valid location breakpoint in a present one of the multiple modules being entered.

Description

    BACKGROUND
  • The present invention relates generally to code debugging in computer systems and, more particularly, to a method for enhancing debugger performance of hardware assisted breakpoints.
  • During development of application programs, developers use a debug program (debugger) to control the flow of application program execution and to inspect aspects of programs. The debugger allows developers to set breakpoints at specific locations in an application module so that the programmer can step into the code line-by-line, or resume execution of the program as required. Breakpoints corresponding to an address (termed “location breakpoints”) are resolved with assist from a hardware event facility. When an instruction is fetched from an address range being monitored by a hardware event facility, the facility will notify the debugger and the debugger will stop an application and display the location. Debugger location breakpoints that represent respective addresses are used to create the hardware event facility address range. Debuggers may also use breakpoints that are not hardware assisted.
  • In order to monitor multiple addresses, the hardware event facility maintains a single address range. That is, if a first location breakpoint is set for address 1000 in the system memory and a second location breakpoint is set for address 2000, then a range is set with a begin address of 1000 and an end address of 2000. Thus, all addresses between (and including) 1000 and 2000 are monitored. Where the begin and end addresses defining a range are far apart from one another, then the hardware event facility is forced to monitor a large address range, which takes more time than monitoring a small address range. As a result, a debugger with active location breakpoints representing a large address range becomes noticeably less efficient. Value would be therefore be added to a debugger if the maximum address range monitored by a hardware event facility could be kept to a minimum.
  • Whenever a debugger user requests to set a breakpoint, it must be validated before it can be accepted by the debugger. The validation process typically ensures that the information provided by the user represents a real program address. If the location breakpoint can be validated then it is set as active, thus affecting the hardware event facility address range. On the other hand, if the breakpoint cannot be validated, the debugger will not allow it to be set.
  • In addition, debuggers may also provide an option in which a deferred breakpoint may be created; that is, a “deferred” breakpoint is one that is validated at a later time. As such, deferred location breakpoints do not affect the hardware event facility address range prior to validation thereof. Conventionally, deferred breakpoints are validated as additional application modules are entered. If a deferred location breakpoint can be validated at such a time, then its state is changed from “deferred” to “active” and it will result in redefining the hardware event facility address range if it falls outside the existing range. If it cannot be validated, the breakpoint remains in a deferred state.
  • Unfortunately, as an application debugged in a conventional manner enters into additional modules, the potential exists for the address range to grow very large as more location breakpoints become active. This has the effect of making the hardware event facility less efficient and will slow the performance of the debugger. Accordingly, it would be desirable to be able to enhance debugger performance of hardware assisted location breakpoints across multiple modules.
  • SUMMARY
  • The above discussed drawbacks and deficiencies of the prior art are overcome or alleviated by a method for enhancing debugger performance of hardware assisted breakpoints across multiple program units. In an exemplary embodiment, the method includes deferring all active location breakpoints within the multiple program units, and subsequently activating each valid location breakpoint in a present one of the multiple program units being entered.
  • In another embodiment, a storage medium includes a machine readable computer program code for enhancing debugger performance of hardware assisted breakpoints across multiple program units, and instructions for causing a computer to implement a method. The method further includes deferring all active location breakpoints within the multiple program units, and subsequently activating each valid location breakpoint in a present one of the multiple program units being entered.
  • In still another embodiment, a computer architecture includes a hardware event facility for monitoring a debugging process of application programming units stored in memory, and a linkage code for executing calls and returns between the application programming units, the linkage code further including a debugger hook handler therein. The debugger hook handler is configured for, upon activation thereof, deferring all active location breakpoints within the application programming units and subsequently activating each valid location breakpoint in a present one of the application programming units being entered.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • Referring to the exemplary drawings wherein like elements are numbered alike in the several Figures:
  • FIG. 1 illustrates a general-purpose computing environment suitable for use in accordance with an embodiment of the invention;
  • FIG. 2 schematically illustrates an application made up of a number of modules, each containing objects that in turn contain functions, and the module linkage code executed during a call or return between functions in different modules;
  • FIG. 3 schematically illustrates module linkage code configured with a debugger hook handler, in accordance with an embodiment of the invention;
  • FIG. 4 is a flow diagram illustrating a method for enhancing debugger performance of hardware assisted breakpoints across multiple program units, in accordance with an embodiment of the invention;
  • FIG. 5(a) is an application sequence flow diagram for a series of hypothetical call/return operations executed between a plurality of modules having location breakpoints included therein; and
  • FIG. 5(b) is a table illustrating a comparison between the resulting address range at various locations in a debugging sequence with and without the use of the methodology shown in FIG. 4.
  • DETAILED DESCRIPTION
  • Disclosed herein is a method for enhancing debugger performance of hardware assisted breakpoints across multiple program units, such as modules. Briefly stated, the state of debugger location breakpoints in a debug session are controlled in a manner such that only the breakpoints for an application module which is currently executing are in an active state, while all others are deferred until such time as their respective units (modules) are entered/re-entered. By limiting the maximum possible address range to a single program unit, the effective address range of a hardware event facility is minimized, thereby improving the performance of a debugger.
  • As used herein, a “program unit” generally refers to a unit of application code with defined entry and exit code to which a debugger hook can be added. Examples of this include functions and modules in the C programming language. That is, all functions in a C program include function linkage code which executes when the function is entered and exited. Similarly, a call to or return to a function in a different program module will execute module linkage code to which a debugger hook can be added.
  • In an exemplary embodiment, the methodology described herein may be implemented through hooks in module linkage code, but can also be applied to similar linkage code such as function linkage. It should therefore be understood that present methodology is not necessarily limited to the scope of module linkage. The method can be applied to any program unit which includes entry and exit code to which a call hook handler can be included. For example, the common concept of a function includes entry and exit linkage code.
  • Referring initially to FIG. 1, there is shown a general-purpose computing environment 100, suitable for use in accordance with an embodiment of the invention. From a program developer's point of view, this is also referred to as the computer architecture. As is shown, the computer architecture 100 includes a central processing unit (CPU) 102, as well as operating system code 104, supporting environment code 106 and application code 108 (the code residing in memory 110 where they may execute). Program developers create application programs by writing source code and compiling source into objects and linking objects into modules and loading those modules to the memory 110 of the computer. As indicated above, the architecture 100 also includes a hardware event facility 112 that assists in the debugging process.
  • FIG. 2 schematically illustrates an application made up of a number of modules 202 (Module A, Module B) each containing objects 204 that in turn contain functions 206. Functions, as is known in the art, are discrete blocks of code which are callable, perform a task and return to their caller. Whenever a function calls to (or returns to) a function in a different module, common environment linkage code 208 will execute as part of the call or return. In conventional debugging techniques, breakpoints that are active in Module A, for example, will remain so even after a call to another function in Module B, which can possibly result in the creation of a larger than necessary address range during the execution of a function in Module B.
  • Accordingly, FIG. 3 schematically illustrates module linkage code 300 that is configured with a debugger hook handler 302, in accordance with an embodiment of the invention. As is shown, the module linkage code 300 and the debugger hook handler 302 execute when a function calls to or returns to a function in a different module. It will be noted that the debugger hook handler only executes if the application is being debugged. An exemplary methodology 400 implemented by the debugger hook handler 302 (and called from the module linkage code 300) is illustrated in the flow diagram of FIG. 4.
  • The process 400 begins with the execution of the debugger hook handler upon being called from the module linkage code, as shown at block 402. Again, from FIG. 3, the linkage code 300 and thus debugger hook handler 302 are called either during a function call or a return. Thus, the process flow 400 can depict either situation. In any case, once the debugger hook handler is called, all active location breakpoints in the application are set to a deferred state, as shown at block 404. Then, at decision block 406, it is determined whether there are any location breakpoints included in the module currently being entered. If not, then the process simply returns back to the module linkage code as shown at block 408.
  • On the other hand, if the module being entered does in fact include location breakpoints therein, then process 400 proceeds to decision block 410 to determine whether a first location breakpoint in the module being entered is valid (e.g., represents a real program address). If so, then the state of the location breakpoint is changed from deferred to active, as shown in block 412; if not, the location breakpoint is not made active. In either instance, the process 400 then reaches decision block 414 to determine whether other location breakpoints are present in the module being entered. If so, the process 400 loops back to decision block 410 and continues until all valid location breakpoints in the module being entered have been changed from deferred to active. Then, the debugger hook handler routine is completed and the process returns back to the module linkage code (block 408). Thus executed, the hook handler process activates deferred location breakpoints in the module being entered prior to module entry.
  • Finally, FIGS. 5(a) and 5(b) demonstrate an exemplary operation of the debugger hook handler for a sequence of call and return operations. In particular, FIG. 5(a) is an application sequence flow diagram for a series of hypothetical call/return operations executed between a plurality of modules (A, B, C) having location breakpoints included therein. FIG. 5(b) is a table illustrating a comparison between the resulting address range after each location in the sequence with and without the use of the above described hook handler methodology.
  • As specifically shown in FIG. 5(a), a first module (Module A) has a begin address (5000) and an end address (6000) with location breakpoints at addresses 5500 and 5600. A second module (Module B) has a begin address (1000) and an end address (2000) with location breakpoints at addresses 1500 and 1700, and a third module (Module C) has a begin address (80000) and an end address (85000) with location breakpoints at addresses 80500 and 80600. In the hypothetical illustrated, there are eight numbered locations along the flow of a program execution.
  • FIG. 5(b) is a table that illustrates the difference in resulting address ranges between a conventional debugging sequence and the methodology illustrated in FIG. 4. In FIG. 5(b), the conventional results are depicted by the designation “without” while the results using the present methodology are depicted by the designation “with.” At location 1, the program has just begun and active location breakpoints are set in module A, while deferred location breakpoints are set in module B and C. The remaining numbered locations represent subsequent locations in the flow of a program. Thus, at location 1, only the location breakpoints in module A are active so the address range is from address 5500 to 5600 (i.e., 100 bytes). This is the case regardless of whether or not the present methodology is implemented.
  • However, at location 2, there is a call from module A to module B. Conventionally, the location breakpoints in module A remain active; thus, upon entering module B the activated location breakpoints therein result in an expanded address range of 4100 total bytes being monitored by the hardware event facility (now from 1500 to 5600). In contrast, since the present methodology deactivates the location breakpoints in module A prior to entering module B, the address range of activated location breakpoints is only 200 bytes in size (from 1500 to 1700). Furthermore, upon return to module A, (location 3) the address range remains at 4100 bytes in a conventional process whereas the address range returns to 100 bytes in the present process (from 5500 to 5600).
  • The advantages of the present methodology become even more apparent upon observing location 6 of the execution flow, during which there is a call from module B to module C. In this instance, it can now be seen that the address range end jumps up to 80,600. As a result, the conventional debugging process now monitors a total address range of 79,100 bytes. In contrast, the present methodology deactivates the location breakpoints in modules A and B, thus keeping the address range down to 100 bytes (80,500 to 80,600). It will further be appreciated that additional modules having addresses at even higher numbers will create larger address ranges as they are entered during function calls. Accordingly, through the present methodology, the hardware event facility address range can be greatly reduced and the efficiency of the debugger improved.
  • In view of the above, the present method embodiments may therefore take the form of computer or controller implemented processes and apparatuses for practicing those processes. The disclosure can also be embodied in the form of computer program code containing instructions embodied in tangible media, such as floppy diskettes, CD-ROMs, hard drives, or any other computer-readable storage medium, wherein, when the computer program code is loaded into and executed by a computer or controller, the computer becomes an apparatus for practicing the invention. The disclosure may also be embodied in the form of computer program code or signal, for example, whether stored in a storage medium, loaded into and/or executed by a computer or controller, or transmitted over some transmission medium, such as over electrical wiring or cabling, through fiber optics, or via electromagnetic radiation, wherein, when the computer program code is loaded into and executed by a computer, the computer becomes an apparatus for practicing the invention. When implemented on a general-purpose microprocessor, the computer program code segments configure the microprocessor to create specific logic circuits. A technical effect of the executable instructions is to implement the exemplary method described above and illustrated in FIG. 4.
  • While the invention has been described with reference to a preferred embodiment or embodiments, it will be understood by those skilled in the art that various changes may be made and equivalents may be substituted for elements thereof without departing from the scope of the invention. In addition, many modifications may be made to adapt a particular situation or material to the teachings of the invention without departing from the essential scope thereof. Therefore, it is intended that the invention not be limited to the particular embodiment disclosed as the best mode contemplated for carrying out this invention, but that the invention will include all embodiments falling within the scope of the appended claims.

Claims (12)

1. A method for enhancing debugger performance of hardware assisted breakpoints across multiple program units, the method comprising:
deferring all active location breakpoints within the multiple program units; and
subsequently activating each valid location breakpoint in a present one of the multiple program units being entered.
2. The method of claim 1, wherein said deferring all active location breakpoints and subsequently activating each valid location breakpoint in a present one of the multiple program units is implemented by a debugger hook handler provided within linkage code.
3. The method of claim 2, wherein said multiple program units further comprise discrete modules.
4. The method of claim 3, wherein said debugger hook handler is activated during both function calls between modules and returns between modules.
5. The method of claim 2, further comprising:
following said deferring all active location breakpoints, determining whether said present program unit being entered contains any location breakpoints therein;
immediately returning to said linkage code where no location breakpoints are present; and
otherwise individually determining whether each location breakpoint is valid and activating the same where valid.
6. A storage medium, comprising:
a machine readable computer program code for enhancing debugger performance of hardware assisted breakpoints across multiple program units; and
instructions for causing a computer to implement a method, the method further comprising:
deferring all active location breakpoints within the program units; and
subsequently activating each valid location breakpoint in a present one of the multiple program units being entered.
7. The storage medium of claim 6, wherein said debugger hook handler is activated during both function calls between program units and returns between program units.
8. The storage medium of claim 6, wherein said multiple program units further comprise discrete modules.
9. A computer architecture, comprising:
a hardware event facility for monitoring a debugging process of application programming units stored in memory; and
a linkage code for executing calls and returns between said application programming units, said linkage code further including a debugger hook handler therein;
wherein said debugger hook handler is configured for, upon activation thereof:
deferring all active location breakpoints within said application programming units; and
subsequently activating each valid location breakpoint in a present one of said application programming units being entered.
10. The architecture of claim 9, wherein said debugger hook handler is activated during both function calls between units and returns between units.
11. The architecture of claim 9, wherein said debugger hook handler is further configured for:
following said deferring all active location breakpoints, determining whether said application programming units in said present unit being entered contains any location breakpoints therein;
immediately returning to said linkage code where no location breakpoints are present; and
otherwise individually determining whether each location breakpoint is valid and activating the same where valid.
12. The architecture of claim 9, wherein said programming units comprise individual modules.
US11/330,452 2006-01-12 2006-01-12 Method for enhancing debugger performance of hardware assisted breakpoints Expired - Fee Related US8108840B2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US11/330,452 US8108840B2 (en) 2006-01-12 2006-01-12 Method for enhancing debugger performance of hardware assisted breakpoints

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US11/330,452 US8108840B2 (en) 2006-01-12 2006-01-12 Method for enhancing debugger performance of hardware assisted breakpoints

Publications (2)

Publication Number Publication Date
US20070174703A1 true US20070174703A1 (en) 2007-07-26
US8108840B2 US8108840B2 (en) 2012-01-31

Family

ID=38287030

Family Applications (1)

Application Number Title Priority Date Filing Date
US11/330,452 Expired - Fee Related US8108840B2 (en) 2006-01-12 2006-01-12 Method for enhancing debugger performance of hardware assisted breakpoints

Country Status (1)

Country Link
US (1) US8108840B2 (en)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10079841B2 (en) 2013-09-12 2018-09-18 Virsec Systems, Inc. Automated runtime detection of malware
US10114726B2 (en) 2014-06-24 2018-10-30 Virsec Systems, Inc. Automated root cause analysis of single or N-tiered application
US10331888B1 (en) * 2006-02-09 2019-06-25 Virsec Systems, Inc. System and methods for run time detection and correction of memory corruption
US10354074B2 (en) 2014-06-24 2019-07-16 Virsec Systems, Inc. System and methods for automated detection of input and output validation and resource management vulnerability
US11409870B2 (en) 2016-06-16 2022-08-09 Virsec Systems, Inc. Systems and methods for remediating memory corruption in a computer application

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5392263B2 (en) * 2008-09-22 2014-01-22 富士通株式会社 Information processing apparatus and memory protection method thereof
US10372590B2 (en) 2013-11-22 2019-08-06 International Business Corporation Determining instruction execution history in a debugger

Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5491793A (en) * 1992-07-31 1996-02-13 Fujitsu Limited Debug support in a processor chip
US5621886A (en) * 1995-06-19 1997-04-15 Intel Corporation Method and apparatus for providing efficient software debugging
US5664159A (en) * 1994-03-08 1997-09-02 Exponential Technology, Inc. Method for emulating multiple debug breakpoints by page partitioning using a single breakpoint register
US6026235A (en) * 1997-05-20 2000-02-15 Inprise Corporation System and methods for monitoring functions in natively compiled software programs
US6052801A (en) * 1995-05-10 2000-04-18 Intel Corporation Method and apparatus for providing breakpoints on a selectable address range
US6126329A (en) * 1993-06-08 2000-10-03 Rational Software Coporation Method and apparatus for accurate profiling of computer programs
US6708326B1 (en) * 2000-11-10 2004-03-16 International Business Machines Corporation Method, system and program product comprising breakpoint handling mechanism for debugging and/or monitoring a computer instruction sequence
US20060070039A1 (en) * 2004-09-30 2006-03-30 International Business Machines Corporation Address watch breakpoints with basing pointers
US20060069959A1 (en) * 2004-09-13 2006-03-30 Sigmatel, Inc. System and method for implementing software breakpoints
US20060294433A1 (en) * 2005-06-28 2006-12-28 Thelen Greg W Debugging using watchpoints

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2752592B2 (en) 1994-12-28 1998-05-18 日本ヒューレット・パッカード株式会社 Microprocessor, signal transmission method between microprocessor and debug tool, and tracing method
US20040040013A1 (en) 2002-08-26 2004-02-26 Mohit Kalra Time-based breakpoints in debuggers
US7225431B2 (en) 2002-10-24 2007-05-29 International Business Machines Corporation Method and apparatus for setting breakpoints when debugging integrated executables in a heterogeneous architecture

Patent Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5491793A (en) * 1992-07-31 1996-02-13 Fujitsu Limited Debug support in a processor chip
US6126329A (en) * 1993-06-08 2000-10-03 Rational Software Coporation Method and apparatus for accurate profiling of computer programs
US5664159A (en) * 1994-03-08 1997-09-02 Exponential Technology, Inc. Method for emulating multiple debug breakpoints by page partitioning using a single breakpoint register
US6052801A (en) * 1995-05-10 2000-04-18 Intel Corporation Method and apparatus for providing breakpoints on a selectable address range
US5621886A (en) * 1995-06-19 1997-04-15 Intel Corporation Method and apparatus for providing efficient software debugging
US6026235A (en) * 1997-05-20 2000-02-15 Inprise Corporation System and methods for monitoring functions in natively compiled software programs
US6708326B1 (en) * 2000-11-10 2004-03-16 International Business Machines Corporation Method, system and program product comprising breakpoint handling mechanism for debugging and/or monitoring a computer instruction sequence
US20060069959A1 (en) * 2004-09-13 2006-03-30 Sigmatel, Inc. System and method for implementing software breakpoints
US20060070039A1 (en) * 2004-09-30 2006-03-30 International Business Machines Corporation Address watch breakpoints with basing pointers
US20060294433A1 (en) * 2005-06-28 2006-12-28 Thelen Greg W Debugging using watchpoints

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10331888B1 (en) * 2006-02-09 2019-06-25 Virsec Systems, Inc. System and methods for run time detection and correction of memory corruption
US11599634B1 (en) 2006-02-09 2023-03-07 Virsec Systems, Inc. System and methods for run time detection and correction of memory corruption
US10079841B2 (en) 2013-09-12 2018-09-18 Virsec Systems, Inc. Automated runtime detection of malware
US11146572B2 (en) 2013-09-12 2021-10-12 Virsec Systems, Inc. Automated runtime detection of malware
US10114726B2 (en) 2014-06-24 2018-10-30 Virsec Systems, Inc. Automated root cause analysis of single or N-tiered application
US10354074B2 (en) 2014-06-24 2019-07-16 Virsec Systems, Inc. System and methods for automated detection of input and output validation and resource management vulnerability
US11113407B2 (en) 2014-06-24 2021-09-07 Virsec Systems, Inc. System and methods for automated detection of input and output validation and resource management vulnerability
US11409870B2 (en) 2016-06-16 2022-08-09 Virsec Systems, Inc. Systems and methods for remediating memory corruption in a computer application

Also Published As

Publication number Publication date
US8108840B2 (en) 2012-01-31

Similar Documents

Publication Publication Date Title
US6708326B1 (en) Method, system and program product comprising breakpoint handling mechanism for debugging and/or monitoring a computer instruction sequence
US9152531B2 (en) Post-compile instrumentation of object code for generating execution trace data
US7761855B2 (en) Computer program product and system for altering execution flow of a computer program
US8327336B2 (en) Enhanced thread stepping
JP4094724B2 (en) Apparatus and method for identifying exceptions when debugging software
US7536605B2 (en) Injection of software faults into an operational system
US8266608B2 (en) Post-compile instrumentation of object code for generating execution trace data
US9244815B2 (en) Integrated debugger and code coverage tool
US9015676B2 (en) Varying removal of internal breakpoints during debugging of code
JP5054115B2 (en) Performing diagnostic operations on asymmetric multiprocessor devices.
US20160299833A1 (en) Multi-threaded debugger support
US20080127117A1 (en) Method and apparatus for instrumentation in a multiprocessing environment
US8108840B2 (en) Method for enhancing debugger performance of hardware assisted breakpoints
US7945900B2 (en) Debugging tool for debugging multi-threaded programs
US8806447B2 (en) Step-type operation processing during debugging by machine instruction stepping concurrent with setting breakpoints
US8843899B2 (en) Implementing a step-type operation during debugging of code using internal breakpoints
JP5270330B2 (en) Multicore microcomputer system simulation method and simulation apparatus
JP2003131902A (en) Software debugger, system-level debugger, debug method and debug program
US9361205B2 (en) Code coverage framework
US7991985B2 (en) System and method for implementing and utilizing a zero overhead loop
US20080127118A1 (en) Method and system for dynamic patching of software
US20170270028A1 (en) System, method and apparatus for debugging of reactive applications
US8914274B1 (en) Method and system for instruction set simulation with concurrent attachment of multiple debuggers
US20120117546A1 (en) Run-time Module Interdependency Verification
GB2380831A (en) Debug exception handler and registers

Legal Events

Date Code Title Description
AS Assignment

Owner name: INTERNATIONAL BUSINESS MACHINES CORPORATION, NEW Y

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:GRITTER, DANIEL S.;STRAIT, GERALD B.;WANG, MEI-HUI;AND OTHERS;REEL/FRAME:017418/0542;SIGNING DATES FROM 20060110 TO 20060111

Owner name: INTERNATIONAL BUSINESS MACHINES CORPORATION, NEW Y

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:GRITTER, DANIEL S.;STRAIT, GERALD B.;WANG, MEI-HUI;AND OTHERS;SIGNING DATES FROM 20060110 TO 20060111;REEL/FRAME:017418/0542

REMI Maintenance fee reminder mailed
LAPS Lapse for failure to pay maintenance fees
STCH Information on status: patent discontinuation

Free format text: PATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362

FP Lapsed due to failure to pay maintenance fee

Effective date: 20160131