Using wasm globals to represent data/function addresses in object files

;tldr; should we use globals hold data addresses, even in non-PIC object files.

The current tooling conventions for object files (and the default used by llvm) is to represent data and functions address only in relocations.

Taking the address or a data symbol or function symbol results in the following code:

i32.const <reloc>

Where the reloc exists only in the linking section and is either a R_WASM_MEMORY_ADDRESS_LEB (for data symbols) or R_WASM_FUNCTION_INDEX_LEB (for function symbols).

With the experimental PIC ABI used by emscripten these address are instead model as wasm globals and produces the following pattern.

global.get <reloc>

In this case the relocation type is R_WASM_GLOBAL_INDEX_LEB.

When linking object built with -fPIC into static binaries that linker creates internal immutable globals that represent the static address of the symbol. Because the global is internal and immutable wasm-opt can then completely eliminate the global and replace the global.get with an i32.const. This can be though of as form of linker relaxation that happen in the post-link optimizer. With a little work we could teach wasm-ld to perform this relaxation directly.

My suggestion is to use globals in similar fashion by default and even when -fPIC is not specified. Here are some of the advantages, as I see them:

1. It simplifies llvm, having just one way to get symbol addresses.
2. It means more comaptability between object files. (-fPIC object need no longer be special)
3. We can use the name section to name wasm globals (https://github.com/WebAssembly/wabt/pull/1554) which means that inspecting object files will give much clearer results. The llvm symbol names can appear the output of normal wasm disassemblers such as wasm2wat and wasmdis, whereas this information was previously hidden in the relocation data.
4. Undefined data symbols can now be represented as imports by the linker. Previously there is now way for the linker to turn an undefined data symbol into an import which is why --allow-undefined doesn't do what most people think it does WRT to data symbols.

Downsides:

1. Unoptimized builds with a lot of global data symbols or address taken functions will have extra wasm globals. (wasm-opt can remove all of these).

The issue names no repository files or tests. Start by reading the object-file relocation conventions and the experimental PIC ABI described here, then inspect how wasm-ld and wasm-opt handle global and relocation-based addresses. Done would require a decided convention and corresponding tooling changes, but the issue does not define an implementation scope or acceptance test.