Closed jackcmay closed 2 years ago
We're implementing the proposed long term solution, namely the BPF programs will use stack frames of varying size with support from the compiler. The dynamic allocation of stack frames with varying size will be managed by the virtual machine running BPF programs. The resolution of this issue depends on the issue #23481.
In the meantime, our tooling infrastructure doesn't support unoptimized compilation. The Solana SDK's cargo-build-bpf tool always builds release version of smart contracts.
This issue has been automatically locked since there has not been any activity in past 7 days after it was closed. Please open a new issue for related bugs.
Problem
TOB-SOL-020
Currently, the size limit for a BPF program stack frame is 0x1000 bytes. However, when building a BPF program outside of the release profile, or with optimizations disabled, the Solana SDK code exceeds this limit. To accommodate the cases where the problematic code is not actually used by the resulting program, the compiler error about stack frame size is actually a warning. This can have the effect that contract developers become used to seeing these errors in the build logs, and fail to properly triage the ones that are indicative of actual problems. As an example, building the tutorial hello world example using cargo +bpf build --target bpfel-unknown-unknown, results in several errors reported in the Solana SDK code, apart from errors in dependent crates.
Proposed Solution
Short term, if the code causing the too large stack frames are not needed for the BPF feature, consider using conditional compilation directives such as cfg and cfg_attr, to
prevent that code from being built for BPF targets. This would remove the code from the BPF build, eliminating the error. Long term, it is our understanding that the Solana project intends to move away from the fixed stack frame size, and we concur that this is a prudent way to address the identified stack issues. A dynamic stack size does not place a burden on the smart contract developers to ensure this requirement is met, and allows crates that contain code with larger stack frames to be used.