Skip to main content
Technical proposal SIMD-0377 Review

eBPF ISA compatibility

  1. Idea
  2. Draft
  3. Review
  4. Accept
  5. Implement
  6. 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.

Source-backed reading aid · source language: EN

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 required
Validators & operators Impact unknown

No proposal-specific evidence was found for this group.

Action requirement unknown
Users & stakers Impact unknown

No proposal-specific evidence was found for this group.

Action requirement unknown
Governance & ecosystem Impact unknown

No proposal-specific evidence was found for this group.

Action requirement unknown

Exact source revision

Full proposal document

Source-language document. Technical identifiers and evidence remain unchanged. 0616093b2952

Summary

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 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

  • JSET32_IMM -> opcode = 0x46 -> pc += offset if (dst as u32 & IMM as u32) != 0

  • JNE32_IMM -> opcode = 0x56 -> pc += offset if dst as u32 != IMM as u32

  • JSGT32_IMM -> opcode = 0x66 -> pc += offset if dst as i32 > IMM as i32

  • JSGE32_IMM -> opcode = 0x76 -> pc += offset if dst as i32 > IMM as i32

  • JLT32_IMM -> opcode = 0xa6 -> pc += offset if dst as u32 < IMM as u32

  • JLE32_IMM -> opcode = 0xb6 -> pc += offset if dst as u32 <= IMM as u32

  • JSLT32_IMM -> opcode = 0xc6 -> pc += offset if dst as i32 < IMM as i32

  • JSLE32_IMM -> opcode = 0xd6 -> pc += offset if dst as i32 <= IMM as i32

  • JEQ32_REG -> opcode = 0x1e -> pc += offset if dst as u32 == src as u32

  • JGT32_REG -> opcode = 0x2e -> pc += offset if dst as u32 > src as u32

  • JGE32_REG -> opcode = 0x3e -> pc += offset if dst as u32 >= src as u32

  • JSET32_REG -> opcode = 0x4e -> pc += offset if (dst as u32 & src as u32) != 0

  • JNE32_REG -> opcode = 0x56 -> pc += offset if dst as u32 != src as u32

  • JSGT32_REG -> opcode = 0x66 -> pc += offset if dst as i32 > src as i32

  • JSGE32_REG -> opcode = 0x76 -> pc += offset if dst as i32 > src as i32

  • JLT32_REG -> opcode = 0xa6 -> pc += offset if dst as u32 < src as u32

  • JLE32_REG -> opcode = 0xb6 -> pc += offset if dst as u32 <= src as u32

  • JSLT32_REG -> opcode = 0xc6 -> pc += offset if dst as i32 < src as i32

  • JSLE32_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, 2026
@LucasSte

The 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 ↗
@LucasSte

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 ↗
@Lichtso

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 ↗
@deanmlittle

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 ↗
@deanmlittle

Since this been split out from the SIMD, we can resolve this.

GitHub ↗
@simd-botbot

✅ All approvals received! @LucasSte, you can now merge this by commenting /merge. ✅ Status: Ready to merge

GitHub ↗
@simd-botbot

✅ Merge successful! LucasSte(https://github.com/LucasSte)'s PR has been merged.

GitHub ↗

simd.watch community discussion · SIMD-0377

Powered by Giscus · Sign in with GitHub to comment

Community comments load when this section approaches the viewport.

Provenance

Evidence & technical details

Rollout or chain data, source revisions, freshness and integrity.
2

SIMD

Deployment Status

Document lifecycleReview
CategoryCore protocol

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.