Support the WebAssembly object format (Disposition: No)

[fitzgen]

@m4b is this something you would be interested in having in goblin?

[m4b]

@fitzgen Yes, possibly.

What specifically did you have in mind?

So first some clarification, when you say "object format", are you are referring to the web assembly linkable object format?

If so, I wasn't aware its exact on-disk format was stabilized (or even approved into the wasm standard?)

If you mean the regular wasm format, I originally considered adding support, and I suppose could integrate, but afaik, there are several working (if not robust) web assembly parsers on crates.io as we speak?

So:

I'm leaning more towards object format, but honestly only if its stabilized/in the standard, than regular wasm format.

But I'm also not philosophically opposed to adding everything either, though it is nice that goblin more or less deals with the "native executable formats", whatever that means (and its not really true since we also parse archives).

Anyone else feel free to chime in if they want/don't want this feature.

[fitzgen]

Basically, wasm defines another binary format for libraries and executables, and if goblin is trying to exhaustively support binary formats that are widely in use today (or likely to be widely in use soon), then I think it is worth considering supporting wasm. Maybe by re-exporting or wrapping parity-wasm's parser.

Didn't really think any further than that.

So first some clarification, when you say "object format", are you are referring to the web assembly linkable object format?

No, just the normal wasm binary encoding.

If you mean the regular wasm format, I originally considered adding support, and I suppose could integrate, but afaik, there are several working (if not robust) web assembly parsers on crates.io as we speak?

Yes, parity-wasm is pretty great, all things considered.

[le-jzr]

Basically, wasm defines another binary format for libraries and executables, and if goblin is trying to exhaustively support binary formats that are widely in use today

I don't think that would even be feasible. While wasm is a sort of "special", there are plenty of other executable binary formats widely in use. Java bytecode, CLR, plenty of other bytecode formats. Any one of which would present a formidable task to support and maintain.

I think wasm in particular needs a special-purpose tool, and trying to mangle it onto any sort of generic API would be a pointless effort.

So in my opinion, the decision tree is a simple one: "Does it make sense for objcopy to support this format? Yes -> goblin may support it. No -> goblin shouldn't support it."

[m4b]

So I am leaning towards not adding wasm binary backends to goblin (with reasoning similar to @le-jzr 's objcopy "test" :) ) ; though adding it in the future is certainly plausible if there's enough demand. However, given that there are several other crates which haven already implemented the lion's share of features for wasm object parsing, it may not be the best use of time resources.