Emit position-independent wasm for relocatable objects

[Anton-4]

Every wasm32 output starts as a relocatable object that another linker consumes afterwards, but parts of that object embedded absolute data addresses. A shared link (wasm-ld -shared, emscripten -sSIDE_MODULE) rejects those, so an output: Archive platform could not be handed to emcc to build a side module:

wasm-ld: error: relocation R_WASM_MEMORY_ADDR_SLEB cannot be used
against symbol `roc.msg.1`; recompile with -fPIC

Two independent sources, one per backend:

• llvmObjectUsesPic enabled PIC only for output: Shared, so the LLVM app object for output: Archive was compiled non-PIC (.roc.bytes.N sites under --opt=speed/size). It now returns true for every wasm32 target, since none of them produce a directly-runnable artifact.

• WasmCodeGen hardcoded memory_addr_sleb / table_index_sleb for generated static-data and function-table addresses (roc.msg.N sites under --opt=dev). Relocatable output now emits the __memory_base / __table_base relative forms instead.

Final in-memory codegen is deliberately unchanged: it still emits an absolute const and keeps the relocation edge only so DCE can trace data liveness.

The final-link path defines both base globals as constant zero, so the wasm produced for output: Shared/Exe still addresses data absolutely. LLVM already emitted this same sequence 100+ times per build, so the merge and relocation-patching paths were already exercised by it.

[greptile-apps]

Confidence Score: 5/5

The implementation appears safe to merge, with only the non-blocking absence of a real shared-link integration test remaining.

Findings

1.  Shared-link behavior remains untested ▶

Summary

The PR makes wasm32 relocatable objects position-independent across both code-generation backends.

• LLVM wasm32 objects now always enable PIC.
• The development backend emits memory and table references relative to __memory_base and __table_base.
• New unit and archive-level tests verify emitted relocation forms for both backends.
• The archive checks still stop short of performing the shared/SIDE_MODULE link covered by the existing unresolved review thread.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart LR
    A[Roc wasm32 build] --> B{Backend}
    B -->|Development| C[Relative memory/table relocations]
    B -->|LLVM| D[PIC object generation]
    C --> E[Relocatable wasm archive]
    D --> E
    E --> F[Foreign wasm linker]
    F --> G[Shared module or final wasm]

Loading

_{Reviews (2) · Last reviewed commit: "Cover wasm PIC output with emission and ..."}

[greptile-apps]

Shared-link behavior remains untested

This test only checks that llvmObjectUsesPic returns true; it never compiles or links a relocatable object. The behavior introduced here depends on the emitted global.get sequence, relocation encodings, base-global imports, and linker handling. Without an end-to-end test that links representative static-data and function-table references through wasm-ld -shared or the SIDE_MODULE flow for both affected backends, the incompatibility this PR fixes—or a later error in relocation or addend encoding—could regress while this test continues to pass.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!