eh pointer encoding {eh_pe:?} not supported for symbol targe

Error message

eh pointer encoding {eh_pe:?} not supported for symbol targets

What it means

In the cranelift DWARF/EH-frame writer, non-absolute eh pointer encodings (DW_EH_PE_*) can only be applied to Address::Constant; when the pointer refers to a symbol and the encoding is anything other than DW_EH_PE_absptr, the writer panics with unimplemented!() because relative/pcrel encodings for symbol targets are not implemented.

Source

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

                    unreachable!("Symbol {} in DWARF not recognized", symbol);
                }
            }
        }
    }

    fn write_eh_pointer(
        &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

Update Wasmer to the latest version
Use DW_EH_PE_absptr-compatible targets (mainstream Linux x86_64/aarch64)
Disable EH/unwind-info generation or strip wasm EH from the module
Use the LLVM backend, which supports the full range of EH pointer encodings

Example fix

// before
Address::Symbol { .. } => {
    unimplemented!("eh pointer encoding {eh_pe:?} not supported for symbol targets")
}
// after
Address::Symbol { .. } => {
    return Err(CompileError::Codegen(format!("eh pointer encoding {eh_pe:?} not supported for symbol targets")));
}

Defensive patterns

Strategy: validation

Validate before calling

// Only DW_EH_PE_absptr is supported for symbol targets in cranelift
fn symbol_target_supported(eh_pe: gimli::constants::DwEhPe) -> bool {
    eh_pe == gimli::constants::DW_EH_PE_absptr
}

Type guard

fn is_absptr(eh_pe: gimli::constants::DwEhPe) -> bool { eh_pe == gimli::constants::DW_EH_PE_absptr }

Prevention

Compile EH modules only on targets whose CFI conventions use absolute encodings
Use LLVM backend for relative-encoding targets
Disable EH/unwind info for experimental targets
Watch Wasmer releases for expanded eh-pointer encoding support

When it happens

Trigger: write_eh_pointer receives Address::Symbol with an eh_pe encoding other than DW_EH_PE_absptr while emitting .eh_frame (personality or LSDA pointers) for a module compiled with cranelift and EH info.

Common situations: Compiling wasm exception-handling modules where the gimli dwarf writer selects a relative encoding (e.g. DW_EH_PE_pcrel/sdata4) for symbol references; using targets whose CFI conventions require relative encodings.

Related errors

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