Function Return Translation Using Stack-Based Address Mapping
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Dynamic binary translation incurs significant performance overheads due to frequent context switches when accessing a lookup table for function return instructions, as existing solutions require an independent data structure to store mapping relationships between source and target program counters, which consumes storage space and necessitates repeated checks on return instruction addresses.
Innovation Solution
The method reuses the running stack space to store mapping results between source and target program counters, eliminating the need for an independent data structure and reducing overheads by sensing changes in return instructions without repeated checks, thus optimizing function return translations.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If a lookup table structure is used to store mapping relationships between source and target program counters, then the translation of indirect jump instructions can be achieved, but storage space is consumed and translation overheads increase due to frequent context switches
Solution Approach 1:
The running stack space, originally designed for storing execution context, is extended to also store address mapping results. This multi-functional use eliminates the need for a separate lookup table structure, reducing storage overhead while maintaining translation capability.
Solution Approach 2:
The patent combines the address mapping storage function with the existing running stack space. By merging these two functions into a single data structure, the system avoids the overhead of maintaining a separate lookup table and reduces context switch frequency.
2Reliability
If the lookup table is accessed each time a function return is performed, then the return address can be retrieved, but frequent context switches cause large performance loss
Solution Approach 1:
The address mapping results are pre-stored in the running stack space during the translation phase. When a function return is executed, the mapping is already available in the stack, eliminating the need for real-time lookup table access and reducing context switches.
Solution Approach 2:
The running stack space acts as an intermediary between the translation process and execution. It caches the address mapping results, serving as a buffer that eliminates direct access to the lookup table during function returns, thereby reducing context switch overhead.
3Reliability
If an independent data structure is used to store mapping relationships, then the mapping can be maintained, but storage space is wasted
Solution Approach 1:
The running stack space is made multi-functional by enabling it to store both execution context information and address mapping results. This eliminates the need for dedicated storage for mappings, optimizing space utilization without compromising mapping maintenance.
Data Source
AI summary
Embodiments of this application disclose an instruction translation method. The method includes: obtaining a return instruction of a function call instruction; obtaining a first address mapping result based on a second address indicated in the return instruction; storing the first address mapping result in a running stack space; and obtaining a first translation result of the return instruction, where the first translation result is a binary translation result of the return instruction, and the second translation result indicates to obtain, from a target location, an instruction indicated by the first address mapping result and execute the instruction. In this application, a running stack space of a source program is reused, thereby saving a storage space. In addition, an address of a return instruction does not need to be checked each time the return instruction is translated, thereby reducing overheads during translation and increasing program running efficiency.