Input Output Data Transformations for Emulated Code Execution

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Identifying and debugging undesired software behaviors in complex applications is challenging due to their rarity and difficulty in reproduction, especially when triggered by various factors like data inputs and race conditions, making it time-consuming to determine root causes.

Innovation Solution

Emulating the execution of non-traced code using trace data from a recorded execution of related traced code, allowing for transformations in input/output locations, sizes, formats, and instruction set architectures to enable debugging and bug identification across different compiler versions and optimizations.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If conventional diagnostic tools (debuggers, profilers) are used on live forward-executing code, then real-time debugging capability is achieved, but time-consuming manual analysis and difficulty in reproducing rare behaviors occur

Engineering Contradiction:
Improvedebugging accuracyVSAvoidtime to identify and reproduce undesired behaviors
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The system performs preliminary tracing of code execution to record detailed state information (register values, memory contents, instruction sequences) before debugging analysis is needed. This recorded execution trace serves as a reusable basis for multiple debugging sessions, eliminating the need to manually reproduce rare behaviors repeatedly.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The invention creates a copy of the code execution trace in a trace file, which can be replayed and analyzed multiple times without re-executing the original code. This allows developers to examine the same execution path repeatedly, improving debugging efficiency while maintaining accurate reproduction of rare behaviors.

Inventive Principle:
Principle #26Copying

2Productivity

If different compilers or compiler settings are used to generate executable code, then code optimization and performance improvement are achieved, but functional differences and compiler bugs may be introduced

Engineering Contradiction:
Improvecode execution performanceVSAvoidfunctional consistency across compiler versions
Core Design Contradiction:
ProductivityVSReliability

Solution Approach 1:

The trace file serves as an intermediary that captures the actual execution behavior of one compiler version and enables analysis of another compiler version's output. By comparing traced execution against emulated execution, the system can identify functional differences introduced by different compilers without requiring both versions to execute simultaneously.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The system changes the parameter being tested from compiler optimization level to compiler version identity. By holding the source code constant and varying only the compiler version, the trace-based comparison method isolates compiler-specific behavioral differences while controlling for other variables.

Inventive Principle:
Principle #35Parameter changes

3Reliability

If source code changes are made to address undesired behaviors, then bug fixes are implemented, but new undesired behaviors may be introduced and verification is time-consuming

Engineering Contradiction:
Improvesoftware behavior correctnessVSAvoidtime to verify bug fixes and detect regressions
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The system performs preliminary tracing with the original code to establish a baseline execution trace. After bug fixes are applied, the same trace can be replayed against the modified code to automatically verify that the fix resolves the original issue and does not introduce new problems, significantly reducing verification time.

Inventive Principle:
Principle #10Preliminary action

4Measurement precision

If optimized code is traced for debugging, then real-world execution accuracy is achieved, but difficulty in reasoning about execution behavior occurs

Engineering Contradiction:
Improveexecution trace accuracyVSAvoiddebuggability and reasoning ease
Core Design Contradiction:
Measurement precisionVSEase of operation

Solution Approach 1:

Instead of directly debugging optimized code, the system traces the optimized code execution and then emulates it using unoptimized code. This inversion allows developers to reason about the optimized code's behavior through the lens of more readable unoptimized code, maintaining trace accuracy while improving debuggability.

Inventive Principle:
Principle #13The other way round (Inversion)

Data Source

PatentUS11281560B2Input/output data transformations when emulating non-traced code with a recorded execution of traced code
Publication Date: 2022.03.22 MICROSOFT TECHNOLOGY LICENSING LLC
  • US11281560B2 patent drawing
  • US11281560B2 patent drawing
  • US11281560B2 patent drawing

AI summary

Transforming input data to enable execution of second executable code using trace data gathered during execution of first executable code. A trace of an execution of the first code is accessed. The trace stores data of an input that was consumed by first executable instructions of the first code. It is determined that the stored data of the input is usable as an input to second executable instructions of the second code. A difference in size/format of the stored data as used by the first instructions, compared to an input size/format expected by the second executable instructions, is identified. Based on the identified difference, a data transformation is determined that would enable the second instructions to consume the stored data. Execution of the second instructions is emulated using the stored data, including projecting the data transformation to enable the second instructions to consume the stored data.