wasm2obj: Implement memory initializers

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?

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.

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

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.

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 😆

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.

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...