eBPF ISA compatibility
- Idea
- Draft
- Review
- Accept
- Implement
- Active
Decision brief
Why this proposal matters
This SIMD introduces instruction set architecture (ISA) changes to make the sBPF virtual machine compatible with the latest existing version of eBPF ISA generated by its LLVM backend. It reverts past ISA changes, modifies the encoding of existing instructions and brings new instructions to the Solana virtual machine.
Proposal at a glance
What changes
- JEQ32_IMM -> opcode = 0x16 -> pc += offset if dst as u32 == IMM as u32
- JGT32_IMM -> opcode = 0x26 -> pc += offset if dst as u32 > IMM as u32
- JGE32_IMM -> opcode = 0x36 -> pc += offset if dst as u32 >= IMM as u32
Stakeholder map
Who is affected
Builders & client teams Medium impact
Programs containing the instructions mentioned in this SIMD must have the 0x03 value in the e_flags field of their header.
Action may be requiredValidators & operators Impact unknown
No proposal-specific evidence was found for this group.
Action requirement unknownUsers & stakers Impact unknown
No proposal-specific evidence was found for this group.
Action requirement unknownGovernance & ecosystem Impact unknown
No proposal-specific evidence was found for this group.
Action requirement unknownExact source revision
Full proposal document
0616093b2952Summary
This SIMD introduces instruction set architecture (ISA) changes to make the sBPF virtual machine compatible with the latest existing version of eBPF ISA generated by its LLVM backend.
It reverts past ISA changes, modifies the encoding of existing instructions and brings new instructions to the Solana virtual machine.
Motivation
The eBPF target on the Rust compiler emits code by default for eBPFv1, whose
only incompatibility with the Solana virtual machine is the callx
instruction. Aiming to prioritize Solana programs and decrease their CU
consumption, we want to be compatible with at least the current eBPF version
(v3), which brings in new instructions. In order for that to be possible, we
must modify our virtual machine to support eBPF integrally.
Dependencies
This proposal depends on the following previously accepted proposals:
SIMD-0178: SBPF Static Syscalls
SIMD-0189: SBPF stricter ELF headers
This SIMD requires static syscalls which requires stricter ELF headers.
New Terminology
The set containing these new instructions will form an sBPFv3 program.
Detailed Design
ELF Identification
Programs containing the instructions mentioned in this SIMD must have the
0x03 value in the e_flags field of their header.
JMP32 instruction class
The JMP32 instruction class utilizes 32 bit wide operands for the same operations as the JMP class.
The following opcodes must be allowed in the verifier and the virtual machine must implement the behavior described below for each one of them.
JEQ32_IMM-> opcode =0x16->pc += offset if dst as u32 == IMM as u32JGT32_IMM-> opcode =0x26->pc += offset if dst as u32 > IMM as u32JGE32_IMM-> opcode =0x36->pc += offset if dst as u32 >= IMM as u32JSET32_IMM-> opcode =0x46->pc += offset if (dst as u32 & IMM as u32) != 0JNE32_IMM-> opcode =0x56->pc += offset if dst as u32 != IMM as u32JSGT32_IMM-> opcode =0x66->pc += offset if dst as i32 > IMM as i32JSGE32_IMM-> opcode =0x76->pc += offset if dst as i32 > IMM as i32JLT32_IMM-> opcode =0xa6->pc += offset if dst as u32 < IMM as u32JLE32_IMM-> opcode =0xb6->pc += offset if dst as u32 <= IMM as u32JSLT32_IMM-> opcode =0xc6->pc += offset if dst as i32 < IMM as i32JSLE32_IMM-> opcode =0xd6->pc += offset if dst as i32 <= IMM as i32JEQ32_REG-> opcode =0x1e->pc += offset if dst as u32 == src as u32JGT32_REG-> opcode =0x2e->pc += offset if dst as u32 > src as u32JGE32_REG-> opcode =0x3e->pc += offset if dst as u32 >= src as u32JSET32_REG-> opcode =0x4e->pc += offset if (dst as u32 & src as u32) != 0JNE32_REG-> opcode =0x56->pc += offset if dst as u32 != src as u32JSGT32_REG-> opcode =0x66->pc += offset if dst as i32 > src as i32JSGE32_REG-> opcode =0x76->pc += offset if dst as i32 > src as i32JLT32_REG-> opcode =0xa6->pc += offset if dst as u32 < src as u32JLE32_REG-> opcode =0xb6->pc += offset if dst as u32 <= src as u32JSLT32_REG-> opcode =0xc6->pc += offset if dst as i32 < src as i32JSLE32_REG-> opcode =0xd6->pc += offset if dst as i32 <= src as i32
callx encoding
The encoding of callx must change so that the register containing the address to jump to is in the destination register.
callx-> opcode =0x9d-> pc =dst
Stack frame gaps
The virtual machine feature of stack gaps must be disabled for sBPFv3 programs.
Alternatives Considered
We have considered diverging from the eBPF standard by introducing new opcodes and creating specific instructions to the Solana environment. We discarded such an approach to be compatible with the existing LLVM eBPF code generation.
Another consideration was bringing new eBPFv4 instructions to the Solana environment. They are a superset of eBPFv3 and does not conflict with it, so any additions may be included in the future without a breaking change.
Impact
These changes permit a straightforward management of the compiler toolchain, permitting the usage of most of existing upstream tooling.
Security Considerations
None
Evidence graph
Related proposals and rollout
One or more sources are unavailable.
Upstream review record
Upstream discussion & review
GitHub review is editorial context, not evidence of on-chain support, voting, or outcome.
PR #377 · merged SIMD-0377: eBPF ISA compatibility 18 comments and reviews · Mar 30, 2026The idea behind this approach is to provide dynamic stack frames without breaking compatibility with upstream eBPF as it is right now. If eBPF LLVM ever supports dynamic stack frames, but in a different way, we can change our implementation to match what has been adopted there. The original dynamic frames design was to avoid having to preallocate/memset 4k MAXDEPTH. The implementation we have right now with the original design (sbpfv1) still allocates the same amount of memory. Is your idea for users to request in the transaction how much stack space they want? If that is the case, this proposal still allows this, since add64 r10, imm can also decrease the frame size of a function, if the im
GitHub ↗I also wanted to remain conservative on the design to be honest. So far, the LLVM maintainers have had some consensus on the features, but not on the implementation. I think it is fair to assume that whatever option we adopt for dynamic stack frames right now may not be the same one adopted upstream in the future.
GitHub ↗Both LimeChain and JetBrains are developing tooling that relies on dynamic stack frames being enabled, so it would be unwise to remove the feature, as it would break their work. We can increase the default stack frame size in debug mode to solve that.
GitHub ↗I'm not saying "remove this feature and throw it in the trash", it's clear you think it's a reasonable approach. I'm saying this has absolutely nothing to do with eBPF ISA Compatibility. If you split this out into a separate SIMD, we can avoid derailing shipping this SIMD on time and direct whatever criticisms we have of the dynamic stack frame design to the new SIMD. I don't think they should be bundled into one proposal like this, especially when it would do no harm to introduce this feature later if we decided we wanted it.
GitHub ↗Since this been split out from the SIMD, we can resolve this.
GitHub ↗✅ All approvals received! @LucasSte, you can now merge this by commenting /merge. ✅ Status: Ready to merge
GitHub ↗/merge
GitHub ↗✅ Merge successful! LucasSte(https://github.com/LucasSte)'s PR has been merged.
GitHub ↗Provenance
Evidence & technical details
Rollout or chain data, source revisions, freshness and integrity. 2
Provenance
Evidence & technical details
Rollout or chain data, source revisions, freshness and integrity.SIMD
Deployment Status
Feature Gate not yet created
Exact source revision
Sources & integrity
- Proposal document pinned_commit_blob
0616093b2952ed6de52c4a27d66aadd11d48d4f9 - simd-document document · stale · Sep 10, 2026
0616093b2952ed6de52c4a27d66aadd11d48d4f9
One or more sources are unavailable.
simd.watch community discussion · SIMD-0377
Powered by Giscus · Sign in with GitHub to comment
Community comments load when this section approaches the viewport.