Our team is actively developing a Solidity debugger aimed at providing a more robust and intuitive debugging experience for Solidity developers. A key feature of any interactive debugger is the implementation of precise interactive stepping semantics, such as "step to the next statement."
Current Limitation
Our debugger currently relies on a heuristic approach to determine the boundaries of Solidity statements during debugging. This method checks whether the current instruction maps to a different statement than the preceding one. While this heuristic works in many cases, it fails to accurately handle more complex constructs, particularly function calls in Solidity.
Issue Illustrated with Function Calls
In Solidity's compiled code, function calls are typically divided into three sections:
Argument Stack Preparation: The first section pushes arguments onto the stack and maps to the function call.
Function Execution: The second section, encompassing JUMP instructions, corresponds to the statements inside the function body.
Return Value Handling: The final section, which handles return values, maps back to the function call.
The challenge arises because the first and third sections are both mapped to the same function call. This leads to inaccuracies with our current heuristic method. For example, when the debugger is at the last statement of the function body and aims to "step to the next statement," it mistakenly steps back to the function call instead of moving beyond it.
Proposed Enhancement
To overcome this limitation, we suggest annotating the first and last instructions corresponding to the same Solidity statement. This additional information during compilation would allow debuggers to accurately identify each statement's start and end points, thereby improving the implementation of stepping semantics.
Context
Our team is actively developing a Solidity debugger aimed at providing a more robust and intuitive debugging experience for Solidity developers. A key feature of any interactive debugger is the implementation of precise interactive stepping semantics, such as "step to the next statement."
Current Limitation
Our debugger currently relies on a heuristic approach to determine the boundaries of Solidity statements during debugging. This method checks whether the current instruction maps to a different statement than the preceding one. While this heuristic works in many cases, it fails to accurately handle more complex constructs, particularly function calls in Solidity.
Issue Illustrated with Function Calls
In Solidity's compiled code, function calls are typically divided into three sections:
The challenge arises because the first and third sections are both mapped to the same function call. This leads to inaccuracies with our current heuristic method. For example, when the debugger is at the last statement of the function body and aims to "step to the next statement," it mistakenly steps back to the function call instead of moving beyond it.
Proposed Enhancement
To overcome this limitation, we suggest annotating the first and last instructions corresponding to the same Solidity statement. This additional information during compilation would allow debuggers to accurately identify each statement's start and end points, thereby improving the implementation of stepping semantics.