Reloc entries for downstream tools for expressions outside the code and data sections

Wasm contains instructions for execution outside code section, specifically in the initializer expressions such as in the Table Section, Global Section and Element Section. Initially from #153 but I was under the impression that issue also wanted change the meaning of the globals which not just how they are used in the module itself.

Some of these relocations can not be "simply" recovered from the binary, even when compiling with -Wl,-emit-relocs. In particular, I face the problem of externally visible symbols being exposed as globals with the value encoding the symbol's address. For example, wasm-tools dump shows one of these globals defined as

0x14af | 7f 00       | [global 2] GlobalType { content_type: I32, mutable: false, shared: false }
0x14b1 | 41 d3 98 c3 | i32_const value:1100883
       | 00         
  [...]
0x1566 | 2a 5f 57 41 | export Export { name: "_WASM_SPLIT_MARKER_8508f2ddea89dd45version", kind: Global, index: 2 }
       | 53 4d 5f 53
       | 50 4c 49 54
       | 5f 4d 41 52
       | 4b 45 52 5f
       | 38 35 30 38
       | 66 32 64 64
       | 65 61 38 39
       | 64 64 34 35
       | 76 65 72 73
       | 69 6f 6e 03
       | 02         

This exposes the address (1100883) of the _WASM_SPLIT_MARKER_8508f2ddea89dd45version symbol (which is a static _: [u8; _]). There is no relocation entry specifying which symbol the global is targeting though which makes it impossible in general, and still hard in my case, to move data symbols around. Currently, I am hardcoding against the specific encoding of all addresses using i32_const with an immediate value and trying to match symbols with their exported global by name. This is suboptimal and tangentially depends on #153 where a change of this encoding is discussed for better PIC behaviour.

A reloc.GLOBAL section containing relocation entries for the immediates of opcodes in the global section could save me some work and future proof this.

Similarly, relocation entries for the constant expressions/funcindices occuring in the initializer of a Table Section and the elements in the Element Section would be appreciated. In this case though, I expect the current format of initializing the table with nulls or simple function indices to be sufficient for the foreseeable future without needing more complicated expressions so "reconstructing" relocations for these simple cases is simple enough.

EDIT:

For additional annoyance, the symbol above does seemingly not have info that it is exposed, it is defined as

Data {
    flags: SymbolFlags(0x0), // No 1 << 5 or 1 << 7
    name: "_WASM_SPLIT_MARKER_8508f2ddea89dd45version",
    symbol: Some(DefinedDataSymbol { index: 0, offset: 52307, size: 0 })
}

in the linking section. Might be intensional since the binary is already assembled, but makes it even harder to match it up the global. Note also in this case, data section 0 has offset i32_const value:1048576, so the math 1048576+52307=1100883 for the address computation checks out.

Start by reviewing issue #153 and the WebAssembly linking and relocation conventions, then use the wasm-tools dump example to trace initializer expressions in the Global, Table, and Element sections. Done means the convention specifies relocation entries for the requested immediates, constant expressions, and function indices, including how they relate to symbols and existing data relocations.