feat: add support for .so dylib files

[emil916]

add support for .so dylib files
seperate the wasm instructions from runtime code
implement a missing wasi_intruction (prestat)

[gparmer]

Looks great! only small issues around 1. wasmception, 2. clarifying the abi wording, and 3. if ifdefs are necessary or if we can just use separate compilation.

[gparmer]

I don't think that @Others is OK with this.

[gparmer]

Is the only way to do this with ifdefs? I thought we tried to avoid them in awsm as much as possible. Could be misremembering.

[gparmer]

Given your later code, is it accurate to say that this is the complete set of symbols that an environment depends on an awsm module for?

I don't think it captures all of the symbols that a module depends on an environment for, right?

[emil916]

Got rid of the ifdef everywhere...

[emil916]

ended up separating the wasm instructions for all the architectures in the repo (mpx, cortex-m ...)

[emil916]

I did a complete new cleanup on the repo.
Got rid of all the #ifdef I added before. Instead provided a simpler Makefile flag to compile for .so lib.
Got rid of a lot of redundancy over the code base.
Made sure it is backward compatible with wasmception, too.

Sorry, it is very a lot to review I guess. But the majority is just the wat files that were missing a line and a keyword change for new version of the wabt app.

[gparmer]

@Others You OK with this? Just adding a runtime that can run the awsm-generated code in a .so. Useful for dynamic loading of functions, and for testing this scenario (which is what we do in sledge).

[gparmer]

@Others This is an increasingly useful feature to test out interesting support for extensible sandboxes. We're testing strange TLS stuff with it. What do you think about it?

[gparmer]

@Others: A little bit more details, and some thoughts. When we use an extern __thread... on the variable holding the memory base, function indirection array, and globals, it is generating a ton of calls to get_tls. Which means it isn't inlining those values well! This is a pretty significant performance hit. One option to handle this is to simply pass an argument to the struct containing all of these (or 3 separate variables) through all of the functions. This is equivalent, in many ways, to devoting a register to holding it. This would be a significant change to awsm, and is terrifying. But it could really help the dynamic scenario of running sandboxes that aren't LTOed with the runtime, or that use TLS.

Just a little background. Love to hear you thoughts. I know you're busy; I just wanted to write the above while it is in my head.