wat2wasm fails with call_indirect and relocation

[skalogryz]

The following code fails to compile by wat2wasm (v1.12) if relocatable binary (-r) is requested.
Is it expected? (exit code 0xC0000005)
Non-relocatable binary compiles just fine.

(module 
  ;; (type (func (param i32)(param i32)(result i32))) ;; fails, even if present
  (func $add (param i32)(param i32)(result i32)
    get_local 0
    get_local 1
    i32.add
    return
  )
  (table 1 anyfunc)
  (elem (i32.const 0) $add)
  (func $run
    i32.const 4444
    i32.const 5555
    i32.const 0
    ;;call_indirect (type 0) ;; fails
    call_indirect (param i32)(param i32)(result i32) ;; fails
    drop
  )
  (export "run" (func $run))
)

[binji]

Looks like it's not supported. I added an error message for now, so at least it won't crash: #1202.

[skalogryz]

ok, thanks... any plans for the implementation?

[sbc100]

For sure we should implement this. Out of interest what is your use case for the -r flag.. I added while I was developing the wasm object format but I'm curious to know if its actually useful in wabt?

[skalogryz]

but I'm curious to know if its actually useful in wabt?

i'm adding wasm target to freepascal compiler (https://github.com/skalogryz/freepascal/tree/webasm) (https://lists.freepascal.org/pipermail/fpc-pascal/2019-September/056848.html)

The compiler internals make it hard to use tree-structure code of binaryen's wasm-as. That makes wat2wasm the best option so far.

the pascal is modular. Each compiled wasm object file needs to be linked in the end.
(static) linking requires the use of -r flag. (The relocation information generated by the flag worked more or less well for lld, with a little help of an additional tool for some cases)

as for call_indirect specifically. It's (supposed to be) used to implement function pointer calls and virtual methods.

[sbc100]

I see. So your compiler outputs .wat, then you use wat2wasm -r to make your object files, then you link your object files with lld.

Sounds like you are the first real user of wat2wasm -r and as such you may run into more difficulties down the line. For example, there is no way that I know of to include data symbols or data relocations in the .wat format.

@aardappel recently added support for his lobster language, and as part of the he made a language agnostive C++ library (a header-only library I believe) that can be used to directly generate relocatable wasm object files. @aardappel would this a good use for your library? If you use that you wouldn't need wabt at all I think.

[skalogryz]

For example, there is no way that I know of to include data symbols or data relocations in the .wat format.

so far, automatically generated symbols worked fine.

f you use that you wouldn't need wabt at all I think.

a disclaimer to use wabt? :)

[sbc100]

Maybe you don't need data relocations in pascal? But this kind of relocation is currently not representable in wat format (at global scope):

int bar = 1;
int foo = &bar;

In a C toolchain this would generate 8 bytes of static data, the with a relocation (pointing to the symbol bar) in the second 4 bytes.

I'm happy to continue to support and improve -r support :) . I just worry that full support will require at least some amount of work on the wat format.

[aardappel]

@sbc100 looks like the FreePascal compiler is itself written in Pascal, so wholesale adoption of my C++ library is unlikely to work :)

@skalogryz that said, if you want to learn how to output linkable wasm object files that work with LLD, this C++ header is a small amount of self-contained code that writes such a binary, in particular see the function Finish at the end for the linking related code. More documentation on that file.

[skalogryz]

@aardappel thanks. I've actually already started a binary utility myself (https://github.com/skalogryz/wasmbin). As it was mentioned earlier there's no much over the symbol information through the .wat file, so I had to post process the data with the tool after the compilation. (that did help to prevent linking conflicts / errors)

FPC does allow support of internal object file writers. With wasm object format being relatively simple I was hoping to avoid going that path. (adding a compiler target is not the same as maintaining the target). It's more fun to use the new (wasm) features (i.e. threads, exceptions.. etc), rather than keeping implementing them (once they become the part of the standard) :)

[skalogryz]

But this kind of relocation is currently not representable in wat format (at global scope)

No, they don't. The problem is that effective address of bar is not relocatable. Yet the variable, that could hold the effective address is.
(global $addrof_bar i32 (i32.const 0))
once linking is done, it's possible to "relocate" the effective address of 'bar' by changing the value of $addrof_bar constant (i.e. i32.const 0 changes to i32.const 2342). (changing the value means - changing it in binary file). I wouldn't expect wat2wasm to do that though.

[skalogryz]

on the topic of call_indirect relocation.

per this document: https://github.com/WebAssembly/tool-conventions/blob/master/Linking.md#merging-function-sections

There are currently two ways in which function indices are stored in the code section:
...
2. Immediate argument of the i32.const instruction (taking the address of a function).

I don't think that follows WebAssembly text format convention. (the only argument of i32.const allowed is a numeric field and not function index).
looking at the wat2wasm code, i didn't find any support for such feature either.

[sbc100]

But this kind of relocation is currently not representable in wat format (at global scope)

No, they don't. The problem is that effective address of bar is not relocatable. Yet the variable, that could hold the effective address is.
(global $addrof_bar i32 (i32.const 0))
once linking is done, it's possible to "relocate" the effective address of 'bar' by changing the value of $addrof_bar constant (i.e. i32.const 0 changes to i32.const 2342). (changing the value means - changing it in binary file). I wouldn't expect wat2wasm to do that though.

But what you are describing is exactly what the linker is supposed to do. That is what relocations are for.

[sbc100]

on the topic of call_indirect relocation.

per this document: https://github.com/WebAssembly/tool-conventions/blob/master/Linking.md#merging-function-sections

There are currently two ways in which function indices are stored in the code section:
...
2. Immediate argument of the i32.const instruction (taking the address of a function).

I don't think that follows WebAssembly text format convention. (the only argument of i32.const allowed is a numeric field and not function index).
looking at the wat2wasm code, i didn't find any support for such feature either.

Right, this is why the -r flag isn't very useful today as a way to building linkable object files. llvm will generte such code correctly either from C/C++ source or you can write in the .s assembly format something like:

i32.const $foo

The assembler then creates a relocation after the i32.const and the linker resolves the relocation and puts foo in the wasm table to make it indirectly callable.

[sbc100]

In short, the wat format as it stands today is not suitable as a general purpose assembly language. Its can't describe object files in the general case.

[carlsmith]

@sbc100 - I'm using WAT as a first-class assembly language for a fantasy console. There's a runtime with a memory-mapped API, but the user writes all of their code in WAT, and any of their modules can import whatever any other module exports. Do you foresee a problem with that?