Disclosed aspects include identifying basic blocks of a program. For each basic block, the compiler inserts an identifier that includes the function name, and is coupled with a counter variable. In response to generating the identifier coupled with the counter variable, the program is compiled. During program execution, the counter value is incremented in response to a call of the basic block when executing the program. In response to incrementing the counter value, the counter value coupled with the identifier is displayed.
Legal claims defining the scope of protection. Each claim is shown in both the original legal language and a plain English translation.
1. A computer-implemented method for debug management, the method comprising: identifying a set of basic blocks of a program; generating, by a compiler, a counter coupled with an identifier corresponding to a basic block of the program; compiling, in response to generating the counter coupled with the identifier, the program; initiating execution of the program; calling the basic block, wherein calling the basic block indicates to trigger incrementation of the counter; incrementing the counter; detecting, in response to incrementing the counter, an error event which is detached from the basic block; establishing, to tend to the error event which is detached from the basic block, a breakpoint linked with the basic block corresponding with the identifier coupled with the counter; determining, based on an outer-to-inner criterion, a basic block order for debugging; displaying, in response to incrementing the counter, the counter coupled with the identifier corresponding to the basic block of the program; and displaying, to load a single page having the error event, the basic block in the basic block order.
This debug management method identifies basic blocks in a program. The compiler adds a counter and identifier (function name, etc.) to each block. When a block is called during execution, the counter increments. The system detects errors not directly tied to the block and sets a breakpoint linked to the block's identifier and counter to handle these errors. The system determines a debugging order from outer to inner blocks. The counter and identifier are displayed during execution. Finally, the basic blocks are displayed according to the debug order to load a single page having the error event.
2. The method of claim 1 , wherein the counter is a static variable which is allocated at compile-time before the program is executed and spans an entire run of the program, further comprising: using the counter to provide a location reference point.
Building on the debug management method described previously where the compiler adds a counter and identifier to each basic block, with the counter incrementing upon block execution, this enhancement specifies that the counter is a static variable allocated at compile-time, existing throughout the program's run. This static counter is then used to provide a fixed location reference point for debugging purposes, aiding in consistently tracking the program's execution flow and identifying error locations.
3. The method of claim 1 , further comprising: collecting, in response to incrementing the counter, the counter coupled with the identifier; and receiving, in response to collecting the counter coupled with the identifier, a request to step to the basic block corresponding with the identifier coupled with the counter.
Expanding on the debug management method where counters are added to basic blocks and incremented on execution, this version includes collecting the counter and identifier values when the counter increments. In response to this collection, the system can then receive a request to jump directly to the basic block corresponding to that specific counter and identifier, facilitating targeted debugging.
4. The method of claim 1 , wherein displaying the counter coupled with the identifier corresponding to the basic block of the program includes: displaying, by a stack display, the counter coupled with the identifier corresponding to the basic block of the program; and presenting, in an automated fashion without a request from a user for an expanded form, the basic block in the expanded form.
In the debug management method involving counters coupled with identifiers for basic blocks, the display of this information is enhanced. Instead of requiring user interaction, a stack display automatically presents the counter and identifier alongside an expanded view of the basic block. This automated, expanded view occurs without any explicit request from the user, providing immediate context during debugging.
5. The method of claim 1 , further comprising: firing a breakpoint linked with the basic block corresponding with the identifier coupled with the counter; comparing, in response to firing the breakpoint, the counter and a stack counter; and providing, in response to a mismatch of the counter and the stack counter, a mismatch notification to a user.
This addition to the debug management method (involving counters and identifiers in basic blocks) introduces a breakpoint that's triggered in conjunction with a basic block's counter and identifier. When this breakpoint fires, the current counter value is compared to a 'stack counter' (presumably representing the expected value based on the call stack). If these values mismatch, a notification is presented to the user indicating a discrepancy, potentially highlighting issues like stack corruption or unexpected control flow. It alerts the user of a failed run.
6. The method of claim 1 , wherein debug management uses location references to indicate where to stop the program prior to an error location.
Building upon the core concept of using location references in debug management, this clarifies that these references pinpoint where program execution should pause *before* reaching an error location. The debug management system leverages these location references to strategically stop the program's execution flow, allowing for inspection and analysis leading up to the error, rather than directly at the point of failure.
7. The method of claim 1 , further comprising: establishing the breakpoint in a first instruction of a set of code of the program.
Extending the primary debug management method with counters and identifiers, this enhancement specifies that the breakpoint is placed at the very first instruction within a basic block. This ensures that whenever the program enters that particular basic block, the debugger immediately halts execution at the start of that block, providing a consistent and predictable debugging entry point.
8. The method of claim 7 , further comprising: linking the breakpoint in the first instruction with a second instruction in the basic block.
Further refining the breakpoint placement from the previous addition, where the breakpoint is in the first instruction of a basic block, this version links that initial breakpoint to a second instruction within the same basic block. This creates a chain or association between the initial breakpoint and a subsequent point of interest within the block.
9. The method of claim 8 , wherein the second instruction corresponds with the counter coupled with the identifier.
Continuing the refinement of breakpoint linking, this clarifies that the second instruction, linked to the initial breakpoint in the first instruction, specifically corresponds to the counter and identifier that were added to the basic block. Therefore, the breakpoint chain leads directly to the code responsible for managing the debugging information.
10. The method of claim 9 , wherein the first and second instructions are different lines of code.
Expanding on the breakpoint linking to the counter and identifier, this aspect emphasizes that the first instruction (with the initial breakpoint) and the second instruction (linked to the counter/identifier) reside on distinct lines of code. This clarifies that the linked breakpoint isn't simply pointing to the same line, but rather connecting two separate, sequential points within the basic block.
11. The method of claim 10 , wherein the first instruction is located prior to the second instruction in the program.
Complementing the separation of the breakpoint instructions, this further specifies that the first instruction (containing the initial breakpoint) is situated *before* the second instruction (associated with the counter and identifier) within the program's code. This reinforces the concept of a sequential flow, where the debugger first halts at the beginning of the block and then proceeds to the debugging-related code.
12. The method of claim 7 , further comprising: stopping execution at a selected point prior to the error event, wherein the selected point includes the breakpoint in the first instruction, and wherein the error event occurs at a line of code subsequent to the first instruction.
Expanding on using breakpoints to manage debugging, specifically the initial breakpoint in the first instruction, the program stops at a selected point prior to the error event. This selected point includes the breakpoint in the first instruction, and the error occurs later. This enables debugging before the error.
13. The method of claim 3 , further comprising: stepping to the basic block corresponding with the identifier coupled with the counter; and stopping without stepping through an entire run of the program.
Building upon the ability to request a step to a basic block corresponding to an identifier and counter, once the collection of the identifier coupled with the counter is received, the debugging session may step to the specified basic block without stepping through the entire run of the program. This allows a user to jump straight to an area of interest.
14. The method of claim 5 , wherein the mismatch notification indicates that a current run does not exactly match a failed run.
Adding to the mismatch notification generated when the counter and stack counter don't align, the notification explicitly indicates that the current program execution doesn't precisely mirror a previous, failed run. This means the current run has diverged from a previous execution where an error was detected, aiding in identifying intermittent or context-dependent issues.
15. The method of claim 1 , further comprising: determining, using the counter coupled with the identifier, a reference to establish a breakpoint.
Extending the base debug management method using counters and identifiers, this specifies that the counter and identifier combination serves as a direct reference for establishing breakpoints. Instead of relying on line numbers or other traditional methods, the system leverages the generated counter and identifier to pinpoint the exact location where a breakpoint should be set, providing a more robust and context-aware approach.
Cooperative Patent Classification codes for this invention. Click any code to explore related patents in that topic.
April 30, 2015
March 14, 2017
Browse 5M+ US patents with plain-English claim translations and AI-generated analysis.