What causes "write_offset not yet implemented" in wasmerio/wasmer?

Do not request full DWARF debug info with the cranelift backend

write_offset not yet implemented

Error message

write_offset not yet implemented

What it means

The trait impl of gimli::Writer::write_offset for the cranelift DWARF writer is a stub; any attempt by the dwarf-writing machinery to emit a section-relative offset panics. This means full DWARF debug-section emission is not implemented for the cranelift backend.

Source

Thrown at lib/compiler-cranelift/src/dwarf.rs:158

        &mut self,
        address: Address,
        eh_pe: constants::DwEhPe,
        size: u8,
    ) -> Result<()> {
        if eh_pe == constants::DW_EH_PE_absptr {
            self.write_address(address, size)
        } else {
            match address {
                Address::Constant(_) => self.writer.write_eh_pointer(address, eh_pe, size),
                Address::Symbol { .. } => {
                    unimplemented!("eh pointer encoding {eh_pe:?} not supported for symbol targets")
                }
            }
        }
    }

    fn write_offset(&mut self, _val: usize, _section: SectionId, _size: u8) -> Result<()> {
        unimplemented!("write_offset not yet implemented");
    }

    fn write_offset_at(
        &mut self,
        _offset: usize,
        _val: usize,
        _section: SectionId,
        _size: u8,
    ) -> Result<()> {
        unimplemented!("write_offset_at not yet implemented");
    }
}

View on GitHub (pinned to 8c4b9ee9d3)

Solutions

Do not request full DWARF debug info with the cranelift backend
Use the LLVM backend when DWARF debug sections are needed
Update Wasmer and check whether write_offset has since been implemented
Implement write_offset in dwarf.rs if you maintain a fork

Example fix

// before
fn write_offset(&mut self, _val: usize, _section: SectionId, _size: u8) -> Result<()> {
    unimplemented!("write_offset not yet implemented");
}
// after
fn write_offset(&mut self, val: usize, _section: SectionId, size: u8) -> Result<()> {
    self.write_udata(val, size); // or return a proper unsupported error
    Ok(())
}

Defensive patterns

Strategy: fallback

Validate before calling

// Choose backend based on debug-info needs
let backend = if needs_full_dwarf { Backend::LLVM } else { Backend::Cranelift };

Try / catch

// Cranelift panics (unimplemented!) — cannot be caught in Rust; prevent by config
if needs_debug_info {
    panic mitigation: build engine with LLVM instead of Cranelift before compilation
}

Prevention

Never request full DWARF debug sections from the cranelift backend
Use LLVM for debug-info builds
Keep cranelift use limited to eh_frame/unwind info it supports
Add CI checks asserting no debug-info flags are set with cranelift

When it happens

Trigger: Emitting debug sections (e.g. .debug_info, .debug_ranges) that require write_offset — i.e. any DWARF generation path that needs a section-relative offset rather than an absolute address, during cranelift compilation.

Common situations: Requesting DWARF/debug info generation with the cranelift engine; tooling that asks for full debug sections rather than just eh_frame.

Related errors

AI-assisted analysis of wasmerio/wasmer@8c4b9ee9d3 (2026-09-01). Data as JSON: /api/errors/8d445231c0cbdcbc. Report an issue: GitHub.