Should we use ELF as a container format?

[jfbastien]

@sunfishcode and I met with Jim Grosbach (Apple) yesterday and discussed WebAssembly. Jim was asking what our container format would be, and suggested that we may want to consider ELF.

He points out that ELF is already supported in LLVM which would make the backend less special.

I'm not particularly familiar with this topic, but I think it's good to list pros/cons of using ELF, and detail why we'd go with it or not.

[sunfishcode]

ELF has some useful properties, like the ability to have arbitrary optional sections, to split up text and data into multiple sections for various purposes, and pretty broad existing tooling support.

Downsides of ELF for WebAssembly include:

• it embeds concepts like virtual addresses and section/segment offsets in numerous places, which aren't going to map well to WebAssembly
• it carries a fair amount of semantic baggage with respect to things like weak symbols and library semantics (although perhaps to some, accurate emulation of ELF semantics are an advantage)

[titzer]

On Tue, May 19, 2015 at 8:11 PM, Dan Gohman notifications@github.com
wrote:

ELF has some useful properties, like the ability to have arbitrary
optional sections, to split up text and data into multiple sections for
various purposes, and pretty broad existing tooling support.

+0.45

I like ELF, but it will take some more consideration before I'm convinced
it's the right fit for this use case. One big advantage is that there are a
lot of existing tools can work with ELF and it's essentially a known
quantity. Also the notion of initialized .bss section that it is loaded
into a particular address space makes sense for wasm.

Downsides of ELF for WebAssembly include:

• it embeds concepts like virtual addresses and section/segment
  offsets in numerous places, which aren't going to map well to WebAssembly

ELF basically assumes a single linear address space for all entities,
which doesn't map well to the function table concept, but we could, e.g.
map function table numbers into part of the address space. For
architectures like AVR that have separate code and data spaces, they
typically divide the ELF linear space this way.

• it carries a fair amount of semantic baggage with respect to things
  like weak symbols and library semantics (although perhaps to some, accurate
  emulation of ELF semantics are an advantage)

We could settle on a subset of ELF that would allow simplifying decoders.
E.g. we could just mandate the sections that should be ignored (i.e. we
decree they cannot possibly have semantic meaning), that everything is
32-bit little endian, etc. Then we just get a CPU type constant to indicate
webasm ELF binaries.

—
Reply to this email directly or view it on GitHub
WebAssembly/spec#74 (comment).

[lukewagner]

@titzer specifying a subset of ELF sounds like a good idea. Want to make a PR to add a note on this in BinaryEncoding.md?

Also, maybe I'm missing an angle, but I don't see any conflicts with wasm function pointers. Basically, in the most recent iteration implied in AstSemantics.md#calls, there isn't an explicit function table (the polyfill would synthesize the tables) or a priori indices: you just take the AddressOf(function-index). I do think it would be useful to have, in the up-front function list (the one which gives you all the signatures of functions and their offsets so it's easy to do parallel decoding) a flag that must be set for any function which is passed to AddressOf since this a priori knowledge.

[jfbastien]

Would using ELF also be useful for dynamic linking, especially for the function table (instead of __pso_root that we discussed, and/or the callbacks)? What about PLT and GOT?

We can mangle types and versioning in the symbol names, a la C++. I'd be afraid of using C's approach to mangling though!

[lukewagner]

I think we'll be able to generate slightly faster code if directly support linking functions and globals in WebAssembly. For one thing, an engine might choose to avoid a runtime PLT/GOT altogether by directly patching code. Even w/o direct patching, though, since indirect calls in wasm entail an extra load, a hand-rolled PLT call will be slower than a builtin PLT call; the builtin PLT call is basically benefiting from being able to store the raw function address directly in the PLT and knowing it can't be corrupted.

[sunfishcode]

One of the characteristic features of ELF is the concept of having two views over the file contents.

Sections organize the file contents, and segments specify how the contents are to be mapped into memory. Typically, a segment covers multiple sections, but they really are two independent views over the same data. One of the purposes of this abstraction is so that the OS execve code which loads ELF programs into memory can ignore all the details of sections and just focus on making a few bulk segment mappings into the address space instead of digging into the details of each of the sections individually.

There are ways we can shoehorn WebAssembly into this, perhaps by having a processor-specific (PT_LOPROC+x) segment type which says "here is a byte range of all the WebAssembly functions to be compiled", but this abstraction isn't obviously adding much value, since we already know we want a way to specify where all the functions are, where they each begin and end, up front.

[luser]

The big benefits of using ELF vs. inventing our own would be tooling, I think. As mentioned above LLVM already has ELF support, and we'd be able to use tools like objdump for inspecting .wasm files without much trouble. Even without adding any special code to objdump you'd be able to inspect the data and get raw AST bytes out etc, which is pretty useful stuff. If we registered an ELF machine type and added support for that to binutils we could make things very useful.

There are definitely some ELF concepts that aren't going to map well into wasm, but I think defining a subset should constrain the problem a bit. I think it's worth trying, at least, to avoid reinventing wheels.

[flagxor]

Using ELF as a container has practical advantages in terms of porting. I've encountered a number of projects who's build assume all binaries are ELF binaries. PNaCl not using ELF has required some special casing. A few programs also assume they can use extra sections to embed data in binaries.