wasm2obj: Implement memory initializers

[m4b]

of the test files, only call does not have memory initializer. I'd like to see it implemented, or at least stubbed out, so I can examine the object files produced.

RUST_BACKTRACE=1 cargo run --bin wasm2obj -- memory.wasm -o memory.o
    Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
     Running `target/debug/wasm2obj memory.wasm -o memory.o`
%wasm_0x0(0): relocs: []
 error: FIXME: implement data initializers

How much work would it be to implement this, or at least add stubs so it doesn't stop the entire binary emission process?

[sunfishcode]

I just pushed a patch which writes wasm data initializers into faerie data sections. Wasm data initializers have some special semantics that involve more than just prepopulating the contents of a .data section, but if you're just testing object file writing, you don't need to worry about that for now.

[m4b]

Awesome, got it! Yup, I'm just examining the object files and primarily grepping them / gdb disass, and eventually will try to link.

[sunfishcode]

I've now hooked up faerie support in the new llvm2cretonne prototype, including relocations:

$ cat test.ll 
declare void @bar()

define i32 @zero() {
    ret i32 0
}

define i32 @foo() {
    call void @bar()
    %t = call i32 @zero()
    ret i32 %t
}
$ llvm2cretonne --set is_64bit=1 --isa intel -o test.o test.ll 
$ objdump -dr test.o

test.o:     file format elf64-x86-64


Disassembly of section .text.zero:

0000000000000000 <zero>:
   0:	40 b8 00 00 00 00    	rex mov $0x0,%eax
   6:	c3                   	retq   

Disassembly of section .text.foo:

0000000000000000 <foo>:
   0:	e8 00 00 00 00       	callq  5 <foo+0x5>
			1: R_X86_64_PLT32	bar-0x4
   5:	e8 00 00 00 00       	callq  a <foo+0xa>
			6: R_X86_64_PC32	.text.zero
   a:	c3                   	retq   

I expect that for the stuff you're doing, llvm2cretonne will be a better vehicle for exploration than the wasm stuff, because wasm needs special handling in lots of areas. Also, you can directly compare the output with LLVM's own output from llc -filetype=obj test.ll. It looks like faerie is doing what LLVM calls -function-sections and -relocation-model=pic, though I haven't looked into why the relocation for zero is different.

[m4b]

Wowwwww this is so cool ! How many translators does cretonne have ?

And yes I’m definitely doing PIC and function sections (afaics function sections is only applicable to ELF and not mach-o)

At some point could make it do non PIC but I dunno if it’s worth the effort as it’s becoming niche. And also need to get other than X86 relocations working 😆

[sunfishcode]

The wasm ones and the llvm2cretonne prototype are the most complete frontends at the moment. There are a few others that have started, but aren't usable yet.

And yeah, PIC and function sections are definitely the way to go for now.

[m4b]

Re zero relocation, i would have to investigate but my guess is your compiler was very clever and added a relative relocation to the locally defined function so as to avoid routing a callq through the plt table, OR it’s just a bug in faerie ;)

Unfortunately I suspect it’ll be difficult for me to get the llvm-sys crate working, I always have llvm lib linking difficulties on my computer... hopefully will be fine, will try tonight !

EDIT

I got it working; had to pass RUSTFLAGS=-ltinfo to get llvm to link on my system, otherwise i get linker errors for symbols from that lib. Also I dunno how that works, since I figured I would require something like -C link-args=ltinfo but yea, it did its thing...