Dynamic Instrumentation Injection for Debugging Overhead Reduction
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Program debugging is inefficient due to the need for debuggers, which cause significant delays and perturbations in the execution of the debuggee process, especially when using instrumentation features like conditional breakpoints, making them impractical for frequently executed code.
Innovation Solution
The solution involves dynamically injecting debugger-compiled instrumentation directly into the debuggee process, allowing it to execute instrumentation without running the debugger, by saving and restoring the state of target methods and using trampolines to redirect execution, thus reducing the need for debugger involvement.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Measurement precision
If the debugger is involved at every execution of instrumentation (using breakpoints and debugger/debuggee communications with operating system facilities), then the programmer can monitor and control program execution, but the execution speed becomes significantly slower (several orders of magnitude slower) due to the overhead of pausing the debuggee process, executing the debugger, and continuing execution
Solution Approach 1:
The patent extracts the instrumentation execution from the debugger process and places it directly into the debuggee process. The instrumentation code is injected into the target process memory and executed natively by the debuggee without requiring debugger involvement, thus eliminating the overhead of process pausing and debugger execution while maintaining monitoring capabilities
Solution Approach 2:
The patent introduces a trampoline mechanism as an intermediary between the original code location and the instrumentation code. The trampoline saves the original execution state, redirects to instrumentation, and after instrumentation completes, restores the original state and continues execution. This intermediary enables seamless instrumentation execution without debugger involvement
2Measurement precision
If instrumentation points are specified at frequently executed program locations, then the programmer can monitor critical code paths, but the perturbation to execution becomes relatively large even if the condition is never true, making conditional breakpoints impractical
Solution Approach 1:
The instrumentation execution is extracted from the debugger and embedded directly in the debuggee process at the specified code locations. This extraction allows the instrumentation to execute as native code within the target process, eliminating the harmful perturbation caused by debugger involvement while maintaining precise monitoring coverage at frequently executed locations
Solution Approach 2:
The debuggee process becomes self-sufficient in executing its own instrumentation code. The instrumentation is injected into the process memory and executed by the process itself without external debugger intervention. The process saves and restores its own state through the trampoline mechanism, making the system self-service and eliminating the harmful effect of debugger-induced execution perturbation
Data Source
AI summary
The present disclosure simplifies programming debugging by dynamically injecting debugger compiled instrumentation into the debuggee process such that the debuggee process executes the instrumentation without executing the debugger. In one example method, the debugger controls compiling a description of the instrumentation as an instrumentation method. The debugger can then write the instrumentation method into the debuggee. The debuggee can save the state of a target method of the debuggee process at a predetermined location. The debuggee process calls the instrumentation method from the debuggee. In addition, the state of the target method can be restored and the resumed from the predetermined location after the instrumentation method executes.