Stream: git-wasmtime

Topic: wasmtime / PR #12602 Fix UEFI compilation for cranelift-jit

Wasmtime GitHub notifications bot (Feb 17 2026 at 01:24):

RossComputerGuy opened PR #12602 from RossComputerGuy:fix/jit-uefi to bytecodealliance:main:

<!--
Please make sure you include the following information:

• If this work has been discussed elsewhere, please include a link to that
  conversation. If it was discussed in an issue, just mention "issue #...".

• Explain why this change is needed. If the details are in an issue already,
  this can be brief.

Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.html

Please ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->

Fixes enough of the errors to get cranelift-jit compiled to UEFI via:

$ RUSTFLAGS="--cfg uefi_std" cargo build --target aarch64-unknown-uefi

Requires changes to region-rs but it hasn't been touched in 2 years. https://github.com/darfink/region-rs/pull/39

Wasmtime GitHub notifications bot (Feb 17 2026 at 01:39):

RossComputerGuy updated PR #12602.

Wasmtime GitHub notifications bot (Feb 17 2026 at 03:34):

github-actions[bot] added the label cranelift on PR #12602.

Wasmtime GitHub notifications bot (Feb 17 2026 at 04:51):

RossComputerGuy updated PR #12602.

Wasmtime GitHub notifications bot (Feb 17 2026 at 04:52):

RossComputerGuy commented on PR #12602:

[TRACE] cranelift/codegen/src/machinst/lower.rs:413 bb block0 param v0: regs ValueRegs(v192)
[TRACE] cranelift/codegen/src/machinst/lower.rs:422 bb block0 inst inst0 (UnaryImm { opcode: Iconst, imm: Imm64(37) }): result v1 regs ValueRegs(v193)
[TRACE] cranelift/codegen/src/machinst/lower.rs:422 bb block0 inst inst1 (Binary { opcode: Iadd, args: [v1, v0] }): result v2 regs ValueRegs(v194)
[TRACE] cranelift/codegen/src/machinst/lower.rs:493 bb block0 inst inst0 has color 1
[TRACE] cranelift/codegen/src/machinst/lower.rs:502  -> constant: 37
[TRACE] cranelift/codegen/src/machinst/lower.rs:493 bb block0 inst inst1 has color 1
[TRACE] cranelift/codegen/src/machinst/lower.rs:493 bb block0 inst inst2 has color 1
[TRACE] cranelift/codegen/src/machinst/lower.rs:496  -> side-effecting; incrementing color for next inst
[TRACE] cranelift/codegen/src/machinst/lower.rs:1313 arg v1 used, old state Unused, new Once
[TRACE] cranelift/codegen/src/machinst/lower.rs:1313 arg v0 used, old state Unused, new Once
[TRACE] cranelift/codegen/src/machinst/lower.rs:1313 arg v2 used, old state Unused, new Once
[DEBUG] cranelift/codegen/src/machinst/compile.rs:35 Number of CLIF instructions to lower: 3
[DEBUG] cranelift/codegen/src/machinst/compile.rs:39 Number of CLIF blocks to lower: 1
[TRACE] cranelift/codegen/src/machinst/lower.rs:1140 about to lower function: function u0:0(i32) -> i32 tail {
block0(v0: i32):
    v1 = iconst.i32 37
    v2 = iadd v1, v0  ; v1 = 37
    return v2
}

[TRACE] cranelift/codegen/src/machinst/lower.rs:776 lower_clif_block: block block0 inst inst2 (MultiAry { opcode: Return, args: EntityList { index: 13, unused: PhantomData<cranelift_codegen::ir::entities::Value> } }) is_branch false side_effect true value_needed false
[TRACE] cranelift/codegen/src/machinst/lower.rs:810 lowering: inst inst2: return v2


Synchronous Exception at 0x000000014043BF50


Synchronous Exception at 0x000000014043BF50

It seems the example crashes in UEFI. May need help figuring this problem out.

Wasmtime GitHub notifications bot (Feb 17 2026 at 17:02):

cfallin commented on PR #12602:

@RossComputerGuy thanks for the PR.

Unfortunately I don't think there is much that we can go on regarding your observed crash. The quoted log shows normal compilation followed by "synchronous exception", nothing in-between, and you've told us nothing about your environment or what you're trying to do.

I can make some educated guesses -- e.g., have you set pages to have execute permission? Is that a thing in your environment (do you have paging enabled)? Are you properly managing other requirements of the ABI (e.g. stack alignment)? Does the code that you're compiling have any bugs that could result in a bad memory access?

Basically, for an actionable bug report, we need: (i) information about what you're trying to do; (ii) information about what happened; (iii) information about why you believe something else should have happened; (iv) whatever investigation you've done that narrows down where this divergence is occurring, ideally pointing in the direction of a Cranelift issue. Thanks!

Wasmtime GitHub notifications bot (Feb 17 2026 at 17:04):

RossComputerGuy commented on PR #12602:

I did narrow it down to this block:
https://github.com/bytecodealliance/wasmtime/blob/f6418005cd282f32840483709c448cf2e8ac808a/cranelift/jit/examples/jit-minimal.rs#L30-L54

I'll see if I can get more details.

Wasmtime GitHub notifications bot (Feb 17 2026 at 17:08):

cfallin commented on PR #12602:

OK, thanks. That's a function body that returns x + 37, and it compiles to reasonable (and correct) machine code in Cranelift. I suspect there is something wrong with your execution environment in general, which is why I was asking about execute permissions, stack alignment, paging, and all of that.

Wasmtime GitHub notifications bot (Feb 17 2026 at 17:11):

RossComputerGuy commented on PR #12602:

Yes but isn't that block not even executing anything? I thought that's just doing codegen. I do have region set up to work with paging which hopefully is correct. The problem is UEFI doesn't really have stack traces so it's hard to figure out what is going awry.

Wasmtime GitHub notifications bot (Feb 17 2026 at 17:14):

bjorn3 commented on PR #12602:

target-lexicon's default_calling_convention method doesn't look like it handles uefi. Maybe that is the issue? On x86_64 uefi uses the windows callconv.

Wasmtime GitHub notifications bot (Feb 17 2026 at 17:15):

RossComputerGuy commented on PR #12602:

That is correct, however this is aarch64 that I am compiling for.

Wasmtime GitHub notifications bot (Feb 17 2026 at 17:15):

cfallin commented on PR #12602:

Ah, I see, I thought you meant you had narrowed down the exception to the code produced by that IR emission sequence. You mean literally there is a crash in that IR emission sequence...

Do you have a panic handler that can print a panic message at least?

Wasmtime GitHub notifications bot (Feb 17 2026 at 17:18):

RossComputerGuy commented on PR #12602:

Yeah no, it doesn't even get to the point of emitting the binary. I haven't attached a panic handler but I will. I know there's also a UEFI debug protocol which should allow me to attach into the interrupt vector so hopefully I can catch exceptions and deal with them.

Last updated: Feb 24 2026 at 04:36 UTC