“Bad relocation type generated” usually means the toolchain emitted a relocation record your linker, object writer, or target backend does not understand for that WebAssembly instruction pattern.

In this case, the failing test uses floating-point rounding operations like f32.ceil and f32.floor. Those instructions are valid in WebAssembly, but under certain compiler and object-generation paths they may be lowered into helper calls, target-specific stubs, or relocation entries that do not match what the downstream linker expects. The result is a build failure that looks like a code generation bug, even though the WAT itself is correct.

Understanding the Root Cause

The root problem is a mismatch between instruction lowering and relocation emission in the WebAssembly backend. Operations such as ceil, floor, trunc, and nearby math intrinsics are sometimes handled in one of two ways:

1. They are emitted directly as native WebAssembly opcodes.
2. They are transformed into calls to compiler runtime helpers or internal symbols during legalization, optimization, or object emission.

The bug appears when the second path happens and the backend generates a relocation type that is invalid for the symbol reference being created. That can happen for several technical reasons:

• The backend selects a relocation intended for function indices, but the symbol is emitted as a different kind of reference.
• The assembler or object writer assumes a relocation format supported by ELF/Mach-O style targets, but WebAssembly object files require a different relocation encoding.
• A recent compiler change updated opcode lowering without updating the matching relocation mapping logic.
• The linker version is older than the compiler backend and cannot understand a newly emitted relocation record.

With a test like this:

(module
  (func (export "ceil") (param $x f32) (result f32)
    (f32.ceil (local.get $x)))
  (func (export "floor") (param $x f32) (result f32)
    (f32.floor (local.get $x))))

the WAT source is not the bug. The failure happens later, when code generation tries to serialize the instruction stream and associated references into a relocatable object or linked output.

Step-by-Step Solution

The most reliable fix is to verify whether the problem is caused by the compiler backend, the object writer, or the linker, then either upgrade to a version containing the relocation fix or force direct opcode generation where possible.

1. Reproduce with the smallest possible test

Keep the test minimal so you can isolate the exact operation that triggers the bad relocation.

(module
  (func (export "ceil") (param f32) (result f32)
    (f32.ceil (local.get 0))))

If that passes, add the other operations one by one:

(module
  (func (export "ceil") (param f32) (result f32)
    (f32.ceil (local.get 0)))
  (func (export "floor") (param f32) (result f32)
    (f32.floor (local.get 0)))
  (func (export "trunc") (param f32) (result f32)
    (f32.trunc (local.get 0)))
  (func (export "nearest") (param f32) (result f32)
    (f32.nearest (local.get 0))))

This tells you whether the issue is isolated to one intrinsic or affects the whole rounding instruction family.

2. Check whether the backend emits direct opcodes or helper calls

Generate textual assembly, IR, or object dumps depending on your toolchain. If you are using an LLVM-based flow, inspect the intermediate output and relocation table. Look for signs that f32.ceil was rewritten as a call to a runtime helper instead of remaining a direct WebAssembly instruction.

# Example investigation flow
clang --target=wasm32 -c test.c -o test.o
llvm-objdump -r test.o
wasm-objdump -r test.o

If the relocation table shows an unexpected relocation attached to a math helper symbol, you have confirmed the issue is in symbol relocation emission rather than parsing or validation.

3. Upgrade the compiler, assembler, and linker as a matched set

This class of bug is often introduced by version skew. A newer code generator may emit relocation kinds an older linker does not support.

# Example
# Upgrade LLVM/Clang/LLD or your WebAssembly toolchain together
# Avoid mixing a newer compiler with an older wasm linker

Best practice: keep compiler, assembler, object tools, and linker on the same release line.

4. Force direct WebAssembly feature support when available

If your pipeline is lowering standard floating-point instructions into helper calls because of target feature assumptions, enable the proper WebAssembly feature set explicitly.

# Example target flags pattern
clang --target=wasm32 -O2 -matomics -mbulk-memory -c test.c -o test.o

The exact flags depend on your toolchain, but the goal is the same: prevent unnecessary lowering to external helper symbols when the target can encode the instruction natively.

5. If you maintain the backend, fix the relocation mapping

For maintainers working inside the compiler or linker, the real patch usually lives in one of these layers:

• Instruction selection: ensure rounding ops lower directly to wasm opcodes when legal.
• Runtime call lowering: if a helper call is required, emit the correct function-symbol relocation kind.
• Object writer: map the symbol reference to a valid WebAssembly relocation type.
• Linker validation: accept the relocation only if it matches the section and symbol type.

A typical backend-side correction is conceptually like this:

// Pseudocode
if (Opcode == F32Ceil || Opcode == F32Floor) {
  if (Subtarget.supportsNativeFPUnaryOps()) {
    emitWasmOpcode(Opcode);
  } else {
    auto Sym = getRuntimeHelperSymbol(Opcode);
    emitCallWithRelocation(Sym, R_WASM_FUNCTION_INDEX_LEB);
  }
}

The important part is that the relocation kind must match the exact encoding expected for a WebAssembly function reference.

6. Add a regression test

Once fixed, lock it down with a regression test covering all affected unary FP rounding instructions.

(module
  (func (export "ceil") (param f32) (result f32)
    (f32.ceil (local.get 0)))
  (func (export "floor") (param f32) (result f32)
    (f32.floor (local.get 0)))
  (func (export "trunc") (param f32) (result f32)
    (f32.trunc (local.get 0)))
  (func (export "nearest") (param f32) (result f32)
    (f32.nearest (local.get 0))))

Also verify with relocation dumps so the test catches future backend regressions, not just parser-level failures.

Common Edge Cases

• Only debug builds fail: optimization level can change lowering behavior. Test with both -O0 and -O2.
• Only one floating-point opcode breaks: the backend may have a special-case implementation for ceil but not floor, or vice versa.
• The module validates but object linking fails: this strongly suggests the bug is in relocatable object emission, not WAT syntax or wasm semantics.
• The issue appears only on wasm32 or wasm64: relocation encodings can differ across target modes or ABI assumptions.
• LTO changes the outcome: link-time optimization can inline, legalize, or rewrite helper calls differently, exposing relocation mismatches that do not appear in normal builds.
• Imported math helpers trigger the failure: if the backend converts the op into an import call, the relocation may need to target a different symbol table entry class.

FAQ

1. Is the WAT test case invalid because it uses f32.ceil and f32.floor?

No. Those are standard WebAssembly floating-point instructions. If you get “bad relocation type generated,” the problem is almost certainly in the toolchain stage that emits or consumes relocations.

2. Why does this sometimes happen only after upgrading the compiler?

Because compiler backends and linkers evolve together. A new backend may emit relocation records or helper call patterns that an older linker cannot process correctly.

3. What is the fastest workaround if I cannot patch the backend immediately?

First, upgrade the full WebAssembly toolchain as a matched version set. If that is not possible, try changing target flags so the instruction is emitted directly instead of being lowered into a helper call path that produces the invalid relocation.

For long-term stability, treat this issue as a backend relocation bug: reproduce it with a minimal module, inspect emitted relocations, fix or upgrade the relocation mapping, and add a regression test so future changes to floating-point lowering do not reintroduce the same failure.

For reference on WebAssembly binary and relocation behavior, review the relevant toolchain documentation from the WebAssembly project and your compiler/linker release notes from the LLVM project.