US20140325193A1

Movatterモバイル変換

Info

Publication number: US20140325193A1
Application number: US14/324,073
Authority: US
Inventors: Balbir Singh; Maneesh Soni
Original assignee: Lenovo Enterprise Solutions Singapore Pte Ltd
Current assignee: Lenovo International Ltd
Priority date: 2009-12-21
Filing date: 2014-07-03
Publication date: 2014-10-30
Also published as: US8832666B2; US20110154297A1; US9336001B2

Abstract

Techniques for dynamic instrumentation are provided. A method for instrumentation preparation may include obtaining address data of an original instruction in an original instruction stream, obtaining kernel mode data comprising a kernel breakpoint handler, obtaining user mode data comprising a user breakpoint handler, allocating a page of a process address space, creating a trampoline, associating the trampoline with a breakpoint instruction, and replacing the original instruction with the breakpoint instruction. A method for instrumentation may include detecting the breakpoint instruction, calling the kernel breakpoint handler, modifying an instruction pointer via the kernel breakpoint handler such that the instruction pointer points to the trampoline, and executing the trampoline. The system for instrumentation may include a breakpoint setup module and a breakpoint execution module for respectively setting up and completing instrumentation involving the trampoline.

Description

CROSS REFERENCE TO RELATED APPLICATION

The present application is a continuation application of, and claims priority under 35 U.S.C. §120 to, U.S. patent application Ser. No. 12/642,973, filed on Dec. 21, 2009.

BACKGROUND

Dynamic instrumentation of software (e.g., a computer program), is used to collect data (e.g., performance data) with respect to the software without recompiling or rebuilding the software. The collected data, generally may be used to solve deep-rooted problems such as deadlocks, resource contention, memory leaks, etc. In typical computer based systems implementing a kernel mode and a user mode, it is useful to collect data from the kernel mode as well as from the user mode with low overhead. Accordingly, there is a need for dynamic instrumentation solutions that achieve data collection involving both the kernel mode and the user mode with low overhead.

SUMMARY

Dynamic instrumentation involving both the user mode and the user mode may be achieved via instrumentation solutions involving a trampoline. Such instrumentation solutions are disclosed in accordance with the various embodiments described herein. In accordance with these various embodiments, data collection via instrumentation can be achieved with low overhead.

In accordance with a first aspect of the various embodiments described herein, a method for instrumentation preparation is provided. This method involves setting up a breakpoint in preparation for instrumentation. The method may include obtaining address data of an original instruction in an original instruction stream, obtaining kernel mode data comprising a kernel breakpoint handler, obtaining user mode data comprising a user breakpoint handler, allocating a page of a process address space, creating a trampoline, associating the trampoline with a breakpoint instruction, and replacing the original instruction with the breakpoint instruction. The method further may include storing the trampoline in the page and copying the user breakpoint handler to the page.

The trampoline created in accordance with this method may include at least one of a copy of the original instruction, a set of instructions for saving register states and stack data of the original instruction, a set of instructions for performing a call to the user breakpoint handler, a set of instructions for restoring the register states and the stack data of the original instruction, and a set of instructions for performing a jump to the next instruction following the original instruction in the original instruction stream. Moreover, the method step of allocating the page may include mapping the page to the process address space. Furthermore, the method step of associating the trampoline with the breakpoint instruction may include registering the kernel breakpoint handler.

In accordance with a second aspect of the various embodiments described herein, a method for instrumentation is provided. The method may include detecting a breakpoint instruction, calling a kernel breakpoint handler, modifying an instruction pointer via the kernel breakpoint handler such that the instruction pointer points to a trampoline associated with the breakpoint instruction, and executing the trampoline. The trampoline may include a copy of an original instruction in an original instruction stream.

Executing the trampoline in accordance with this method may include executing the original instruction. Moreover, executing the trampoline may include at least one of saving register states and a thread stack of the original instruction and restoring the register states and the thread stack of the original instruction. Furthermore, executing the trampoline may include jumping to the next instruction following the original instruction in the original instruction stream.

In accordance with a third aspect of the various embodiments described herein, a system for instrumentation is provided. The system may include a breakpoint setup module for allocating memory of a process address space, for configuring instrumentation data associated with an original instruction in an original instruction stream, for storing the instrumentation data in the allocated memory of the process address space, and for associating the instrumentation data with a breakpoint instruction. In addition, the system may include a breakpoint execution module for executing a kernel breakpoint handler that modifies an instruction pointer to point to the instrumentation data and for executing the instrumentation data. The instrumentation data may include a trampoline. The trampoline may include at least one of a copy of the original instruction, a set of instructions for saving register states and stack data of the original instruction, a set of instructions for performing a call to a user breakpoint module, a set of instructions for restoring the register states and the stack data of the original instruction, and a set of instructions for performing a jump to the next instruction following the original instruction in the original instruction stream.

Moreover, in accordance with this system, the breakpoint setup module may store at least one of a user breakpoint handler and user mode instructions in the allocated memory of the process address space. Additionally, the breakpoint setup module may associate the instrumentation data with the breakpoint instruction by registering a kernel breakpoint handler. The kernel breakpoint handler may modify the instruction pointer to point to the instrumentation data. Furthermore, the breakpoint setup module may allocate memory of the process address space by mapping a page to the process address space.

In accordance with a fourth aspect of the various embodiments described herein, a computer program product for instrumentation preparation is provided. The computer program product involves setting up a breakpoint in preparation for instrumentation. The computer program product may include a computer readable storage medium having computer readable program code instructions stored therein that may include sets of computer instructions for performing one or more steps of the aforementioned instrumentation preparation method.

In accordance with a fifth aspect of the various embodiments described herein, a computer program product for instrumentation is provided. The computer program product may include a computer readable storage medium having computer readable program code instructions stored therein that may include sets of computer instructions for performing one or more steps of the aforementioned instrumentation method.

BRIEF DESCRIPTION OF THE DRAWINGS

The various embodiments described herein will be described in detail with reference to the following figures.

FIG. 1 is a block diagram illustrating a computing system comprising a dynamic instrumentation system, in accordance with an exemplary embodiment.

FIG. 2 is a dataflow diagram illustrating the dynamic instrumentation system ofFIG. 1 in further detail, in accordance with an exemplary embodiment.

FIG. 3 is a flowchart illustrating a method that can be performed by the dynamic instrumentation system ofFIG. 2 in order to prepare for instrumentation, in accordance with an exemplary embodiment.

FIG. 4 is a flowchart illustrating a breakpoint setup method that can be performed by the dynamic instrumentation system ofFIG. 2, in accordance with an exemplary embodiment.

FIG. 5 is a flowchart illustrating an instrumentation method that can be performed by the dynamic instrumentation system ofFIG. 2, in accordance with an exemplary embodiment.

FIG. 6 is a flowchart illustrating a trampoline execution method that can be performed by the dynamic instrumentation system ofFIG. 2, in accordance with an exemplary embodiment.

The drawings described herein are for illustration purposes only and are not intended to limit the scope of the present disclosure in any way. Throughout the drawings, corresponding reference numerals indicate like or corresponding parts and features.

DETAILED DESCRIPTION

Reference will now be made in detail to the subject matter disclosed, which is illustrated in the accompanying drawings. It will be readily understood that the components of the various embodiments as generally described and illustrated in the figures herein may be arranged and designed in a wide variety of different configurations in addition to the described exemplary embodiments. Thus, the following detailed description of the various embodiments, as represented in the figures, is not intended to limit the scope of the disclosure as claimed but rather is merely representative of the various embodiments.

Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided to give a thorough understanding of embodiments of the invention. However, one skilled in the relevant art will recognize that the various embodiments can be practiced without one or more of the specific details and/or can be practiced with other methods, components, materials, etc. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the various embodiments. The various embodiments described herein will be best understood by reference to the drawings. The following description is intended only by way of example and simply illustrates certain selected exemplary embodiments as claimed herein.

The flowchart and block diagrams in the drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products in accordance with various embodiments. In this regard, each block in the drawings may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the drawings. For example, two blocks shown in succession may be executed substantially concurrently, or the blocks sometimes may be executed in the reverse order, depending upon the functionality involved. Moreover, each block of the block diagrams and/or flowchart illustrations, and combinations of blocks in the block diagrams and/or flowchart illustrations, may be implemented by special purpose hardware-based systems that perform the specified functions or acts or by combinations of special purpose hardware and computer instructions.

FIG. 1 provides a block diagram of anexemplary computing system100 that comprises a dynamic instrumentation system in accordance with an exemplary embodiment. Thecomputing system100 may comprise ageneral purpose computer101. As can be appreciated, thecomputing system100 may comprise a number of computing devices, including but not limited to a desktop computer, a laptop, a server, a portable handheld device (e.g., a PDA, a mobile phone, etc.), or any other electronic device capable of performing computation. The various embodiments described herein will be discussed in the context of thegeneral purpose computer101.

Thecomputer101 may comprise aprocessor102,memory104 coupled to amemory controller106, one or more input and/or output (I/O)devices108,110 (or peripherals) that are communicatively coupled via a local input/output controller112, and adisplay controller114 coupled to adisplay116. Aconventional keyboard122 andmouse124 may be coupled to the input/output controller112. Furthermore, thecomputing system100 may comprise anetwork interface118 for coupling thecomputing system100 to anetwork120. Thenetwork120 may transmit and receive data between thecomputer101 and external systems.

Thememory104 may store instructions that can be executed by theprocessor102. The instructions stored inmemory104 may comprise one or more separate programs, each of which may comprise an ordered listing of executable instructions for implementing logical functions. As illustrated inFIG. 1, the instructions stored in thememory104 may comprise a suitable operating system (OS)126. Theoperating system126 may control the execution of other computer programs and may provide scheduling, input-output control, file and data management, memory management, and communication control and related services.

Theprocessor102 may be configured to execute the instructions stored within thememory104, to communicate data to and from thememory104, and to generally control operations of thecomputer101 pursuant to the instructions when thecomputer101 is in operation. Theprocessor102 may be any custom made or commercially available processor, a central processing unit (CPU), an auxiliary processor among several processors associated with thecomputer101, a semiconductor based microprocessor (in the form of a microchip or chip set), a microprocessor, or any other device for executing instructions.

Theprocessor102 may execute the instructions of adynamic instrumentation system128. Thedynamic instrumentation system128 may be stored in the memory104 (as shown inFIG. 1), may be executed from a portable storage device (e.g., CD-ROM, Diskette, Flash Drive, etc.) (not shown), and/or may be run from a remote location, such as from a central server (not shown).

Generally, thedynamic instrumentation system128 may collect data (e.g., performance data of a program of the computer101). Such data may be collected from a kernel address space (while running in the kernel mode) and a user address space. Thedynamic instrumentation system128 may collect the data non-disruptively and without recompiling or rebuilding the application.

FIG. 2 illustrates thedynamic instrumentation system128 in further detail in accordance with an exemplary embodiment. Thedynamic instrumentation system128 may comprise one or more modules and data stores. As can be appreciated, the modules may be implemented as a combination of software, hardware, firmware, and/or other suitable components that provide the described functionality. Moreover, the modules shown inFIG. 2 may be combined and/or further partitioned to similarly collect data from the kernel address space and the user address space. In this example, thedynamic instrumentation system128 comprises abreakpoint setup module130 and abreakpoint execution module132.

Thebreakpoint setup module130 may receive as inputs aninstrumentation request133,address data134,kernel mode data136, anduser mode data138. Theinstrumentation request133 may be generated based on a user request to instrument an original instruction stream (e.g., a program) with a breakpoint. Theaddress data134 may comprise the text address of an original instruction within the original instruction stream. Thekernel mode data136 may comprise a kernel breakpoint handler154 (which may be an input to thebreakpoint execution module132, as illustrated inFIG. 2 and discussed below) or kernel instrumentation codes that are executed in the kernel mode. Theuser mode data138 may comprise a user breakpoint handler146 (which may be an input to thebreakpoint execution module132, as illustrated inFIG. 2 and discussed below) or user instrumentation codes that are generally executed in the user mode. Based on the inputs, thebreakpoint setup module130 may configure the original instruction stream by inserting a breakpoint instruction.

Thebreakpoint setup module130 may interface with aprocess address space140 associated with theaddress data134. Theprocess address space140 generally stores code, data, and a stack. When theinstrumentation request133 is received, thebreakpoint setup module130 may allocate apage142 of theprocess address space140 to store breakpoint instrumentation information. The allocation of thepage142 of the process address space may be achieved by mapping thepage142 to theprocess address space140, and such mapping may be facilitated viamap data143. Thebreakpoint setup module130 may store in thepage142 theuser mode data138 andtrampoline data144 representing a trampoline.

Thetrampoline data144 may comprise a copy of the original instruction (Original_Instruction_Copy), a set of one or more instructions for saving register states and stack data of the original instruction (Save_Registers( )), a set of one or more instructions for performing a call to the user breakpoint handler146 (Call_User_Breakpoint_Handler( )), a set of one or more instructions for restoring the register states and the stack data of the original instruction ((Restore_Registers( )), and a set of one or more instructions for performing a jump to the next instruction following the original instruction in the original instruction stream (Jump_Next_Instruction). Thebreakpoint setup module130 may define thetrampoline data144 based on the instruction data stored in theprocess address space140.

Thebreakpoint setup module130 may replace the original instruction with the breakpoint instruction viabreakpoint data148. Moreover, thebreakpoint setup module130 may generate aregistration request150 to register thekernel breakpoint handler154 for the breakpoint instruction. The registration of thekernel breakpoint handler154 may associate thetrampoline data144 and otherkernel mode data136 with the breakpoint instruction.

Thebreakpoint execution module132 may receive as inputs anincoming instruction152, thekernel breakpoint handler154, thetrampoline data144, and theuser breakpoint handler146. Theincoming instruction152 indicates the instruction to be processed. When theincoming instruction152 is a breakpoint instruction, thebreakpoint execution module132 may execute thekernel breakpoint handler154 that is registered for the breakpoint instruction.

Thekernel breakpoint handler154 may modify an instruction pointer to point to the trampoline in thepage142 of theprocess address space140. Thekernel breakpoint handler154 may return after modifying the instruction pointer. Thebreakpoint execution module132 then may execute the trampoline by, for example, saving the register states and the stack data of the original instruction, executing theuser breakpoint handler146, restoring the register states and the stack data of the original instruction, executing the original instruction, and jumping to the next instruction following the original instruction in the original instruction stream.

With reference toFIGS. 3-6 and with continued reference toFIG. 2, methods will be described that can be performed by thedynamic instrumentation system128 ofFIG. 2 in accordance with an exemplary embodiment. The methods may involve an original instruction in an original instruction stream. As can be appreciated in light of the disclosure, the order of operation within the methods is not limited to the sequential execution as illustrated inFIGS. 3-6, but rather may be performed in one or more varying orders as applicable and in accordance with the present disclosure. Furthermore, one or more steps of the methods may be added or removed without altering the spirit of the methods.

FIG. 3 illustrates a method that can be performed by thedynamic instrumentation system128 ofFIG. 2 in order to prepare for instrumentation involving the original instruction in accordance with an exemplary embodiment. The process may begin atblock300. The inputs may be monitored for an instrumentation request, and atblock310 it may be determined whether an instrumentation request has been received. When an instrumentation request is received atblock310, a breakpoint may be set up atblock320, as will be further discussed herein in the context ofFIG. 4. Subsequently, it may be determined atblock330 whether the breakpoint setup is successful. If the breakpoint setup is successful, then the process may end atblock350. Conversely, if the breakpoint setup is not successful, then an error message may be sent (e.g., sent to the user) atblock340 before the process ends atblock350. Once the process ends, subsequent instructions in the original instruction stream may be processed in accordance with an instrumentation method further discussed herein in the context ofFIG. 5.

FIG. 4 illustrates a breakpoint setup method that may be performed by thebreakpoint setup module130 ofFIG. 2 in accordance with an exemplary embodiment. The process steps performed in accordance with this method further define the breakpoint setup step previously presented with respect to block320 of the method illustrated inFIG. 3. The process may begin atblock400. The address data (text address)134 of the original instruction may be obtained atblock405, thekernel mode data136 may be obtained atblock410, and theuser mode data138 may be obtained atblock415. Atblock420 it may be determined whether the obtainedaddress data134 is valid. If it is determined that the obtainedaddress data134 is invalid, then an error message may be sent (e.g., sent to the user) atblock425, and the process then may end atblock455. Conversely, if it is determined that the obtainedaddress data134 is valid, then atblock430 additional memory of theprocess address space140 may be allocated in the form of thepage142. The memory allocation may be achieved by mapping thepage142 to theprocess address space140. Subsequently, a trampoline may be created and stored in thepage142 atblock435. As previously discussed with reference toFIG. 2, the trampoline may be represented by thetrampoline data144 and may comprise a copy of the original instruction. Theuser breakpoint handler146 may be copied to thepage142 atblock440. Thekernel breakpoint handler154 may be registered atblock445, and a breakpoint (i.e., breakpoint instruction) may be inserted atblock450. As previously mentioned, the registration of thekernel breakpoint handler154 may associate thetrampoline data144 with the breakpoint instruction. The inserted breakpoint instruction may replace the original instruction. Thereafter, the process may end atblock455. It should be noted that an existing breakpoint may be removed as desired using a process analogous to the process described above.

FIG. 5 illustrates an instrumentation method in accordance with an exemplary embodiment. The process may begin atblock500. Anincoming instruction152 in the original instruction stream may be received atblock510. Then, it may be determined whether theincoming instruction152 is a breakpoint instruction atblock520. That is to say, it may be determined whether a breakpoint hit that causes a breakpoint exception has occurred. If atblock520 it is determined that theincoming instruction152 is not a breakpoint instruction (i.e., there is no breakpoint hit), then the process may end atblock560. Conversely, if it is determined that theincoming instruction152 is a breakpoint instruction (i.e., there is a breakpoint hit), then thekernel breakpoint handler154 may be called atblock530 in order to handle the breakpoint exception. Atblock540, the value of the instruction pointer may be modified by means of thekernel breakpoint handler154 to point to the trampoline stored in thepage142 that is mapped to theprocess address space140. Subsequently, the trampoline may be executed atblock550, as will be further discussed herein in the context ofFIG. 6. Thereafter, the process may end atblock560.

FIG. 6 illustrates a trampoline execution method that may be performed by thebreakpoint execution module132 ofFIG. 2 in accordance with an exemplary embodiment. The process steps performed in accordance with this method further define the trampoline execution step previously presented with respect to block550 of the instrumentation method illustrated inFIG. 5. The process may begin atblock600. The trampoline may save the registers (including the register states) and the thread stack of the original instruction atblock610. The trampoline may execute the user breakpoint handler atblock620. Once the user breakpoint handler is executed, the trampoline may restore the registers and the thread stack of the original instruction atprocess block630. Subsequently, the trampoline may execute the original instruction atblock640 and then may jump to the next instruction after the breakpoint instruction (i.e., the next instruction following the original instruction in the original instruction stream) atblock650. Thereafter, the process may end atblock660.

One or more aspects of the various embodiments described herein may be included in an article of manufacture (e.g., one or more computer program products) comprising a computer readable medium. The computer readable medium may comprise computer readable program code for providing and facilitating the capabilities of the present disclosure. The article of manufacture may be included as a part of a computer system or may be provided separately. Additionally, at least one program storage device readable by a machine, tangibly embodying at least one program of instructions executable by the machine to perform the capabilities of the present disclosure, may be provided.

A computer usable or computer readable medium may be utilized, or any combination of computer usable or computer readable media may be utilized. The computer usable or computer readable medium may be, for example, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, device, or propagation medium. More specific examples (a non-exhaustive list) of the computer readable medium include an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CDROM), an optical storage device, a transmission media such as those supporting the Internet or an intranet, or a magnetic storage device. Note that the computer usable or computer readable medium may be paper or another suitable medium upon which the program is printed, as the program may be electronically captured, via, for instance, optical scanning of the paper or other medium, then compiled, interpreted, or otherwise processed in a suitable manner, if necessary, and then stored in a computer memory. In the context of this disclosure, a computer usable or computer readable medium may be any medium that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. The computer usable medium may include a propagated data signal with the computer usable program code embodied therewith, either in baseband or as part of a carrier wave. The computer usable program code may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc.

Computer program code for carrying out operations of the various embodiments described herein may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++, or the like and conventional procedural programming languages, such as the “C” programming language or similar programming languages. The program code may execute entirely on a user's computer, partly on a user's computer, as a stand-alone software package, partly on a user's computer and partly on a remote computer, or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to a user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).

While exemplary embodiments have been described herein, it should be understood that those skilled in the art, both now and in the future, may make various improvements and enhancements which fall within the scope of the claims which follow. These claims should be construed to maintain the proper protection for the disclosure first described.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. The corresponding structures, features, materials, acts, and equivalents of all means or step plus function elements in the claims below are intended to include any structure, material, or act for performing the function in combination with other claimed elements as specifically claimed. The disclosure has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the various embodiments in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the various embodiments. The exemplary embodiments have been chosen and described in order to best explain the principles of the various embodiments and the practical application, and to enable others of ordinary skill in the art to understand the various embodiments. The various embodiments may include various modifications as are suited to the particular use contemplated.

Claims

1.-5. (canceled)

6. A method comprising:

creating a trampoline associated with a breakpoint instruction, the trampoline comprising a copy of an original instruction in an original instruction stream, a set of instructions for saving register states and stack data of the original instruction, and a set of instructions for restoring the register states and the stack data of the original instruction;

detecting the breakpoint instruction;

calling a kernel breakpoint handler;

modifying an instruction pointer via the kernel breakpoint handler such that the instruction pointer points to the trampoline; and

executing the trampoline by operation of one or more processors, wherein executing the trampoline comprises executing the original instruction.

7.-8. (canceled)

9. The method according toclaim 6, wherein executing the trampoline further comprises at least one of saving the register states and the stack data of the original instruction and restoring the register states and the stack data of the original instruction.

10. The method according toclaim 6, wherein executing the trampoline further comprises jumping to a next instruction following the original instruction in the original instruction stream.

11. A system comprising:

a breakpoint setup module configured to allocate memory of a process address space, configure instrumentation data associated with an original instruction in an original instruction stream, store the instrumentation data in the allocated memory of the process address space, and associate the instrumentation data with a breakpoint instruction, wherein the instrumentation data includes a trampoline comprising a copy of the original instruction, a set of instructions for saving register states and stack data of the original instruction, and a set of instructions for restoring the register states and the stack data of the original instruction; and

a breakpoint execution module configured to execute a kernel breakpoint handler that modifies an instruction pointer such that the instruction pointer points to the trampoline and further configured to execute the trampoline, wherein the breakpoint execution module includes one or more processors, and wherein executing the trampoline comprises executing the original instruction.

12. (canceled)

13. The system according toclaim 11, wherein the trampoline comprises at least one of a set of instructions for performing a call to a user breakpoint module and a set of instructions for performing a jump to a next instruction following the original instruction in the original instruction stream.

14. The system according toclaim 11, wherein the breakpoint setup module is further configured to store at least one of a user breakpoint handler and user mode instructions in the allocated memory of the process address space.

15. The system according toclaim 11, wherein the breakpoint setup module is further configured to associate the instrumentation data with the breakpoint instruction by registering a kernel breakpoint handler.

16. (canceled)

17. The system according toclaim 11, wherein the breakpoint setup module is further configured to allocate memory of the process address space by mapping a page to the process address space.

18. The method according toclaim 6, further comprising:

allocating a page of a process address space; and

storing the trampoline in the page.

19. The method according toclaim 18, wherein allocating the page comprises mapping the page to the process address space.

20. The method according toclaim 6, wherein the trampoline further comprises at least one of a set of instructions for performing a call to a user breakpoint handler and a set of instructions for performing a jump to a next instruction following the original instruction in the original instruction stream.

21. The system according toclaim 11, wherein executing the trampoline further comprises at least one of saving the register states and the stack data of the original instruction and restoring the register states and the stack data of the original instruction.

22. The system according toclaim 11, wherein executing the trampoline further comprises jumping to a next instruction following the original instruction in the original instruction stream.

23. A computer program product including a non-transitory computer readable medium having program code instructions embodied therewith, the program code instructions executable by a computing device to perform an operation comprising:

detecting the breakpoint instruction;

calling a kernel breakpoint handler;

24. The computer program product according toclaim 23, wherein executing the trampoline further comprises at least one of saving the register states and the stack data of the original instruction and restoring the register states and the stack data of the original instruction.

25. The computer program product according toclaim 23, wherein executing the trampoline further comprises jumping to the next instruction following the original instruction in the original instruction stream.

26. The computer program product according toclaim 23, further comprising:

allocating a page of a process address space; and

storing the trampoline in the page.

27. The computer program product according toclaim 26, wherein allocating the page comprises mapping the page to the process address space.

28. The computer program product according toclaim 23, wherein the trampoline further comprises at least one of a set of instructions for performing a call to a user breakpoint handler and a set of instructions for performing a jump to a next instruction following the original instruction in the original instruction stream.