wasm2c in freestanding environment

[douglas-raillard-arm]

Opening this issue as a narrowed-down version of #1949 to track freestanding-related questions.

I didn't end up using wasm2c in the original use case mentioned there for reasons completely unrelated to wasm, but I very recently considered using it for another task, again in the same environment (kernel out of tree driver, basically identical to embedded development context).

The only remaining issue seems to be:

1. the inclusion of helper functions for some opcode, like wasm_trunc().
2. the inclusion of some stdlib headers that may not be available in a freestanding environment [1]

Point 1. is relatively easy to deal with by providing custom trapping implementations of the libc functions they rely on, but it would be nice for embedded use case to simply fail to compile floating point opcodes, rather than emitting a call to something.

Headers of point 2. can be removed by editing the C file after generation or providing them with an empty content, but it would be nicer to allow direct customization of the content. As it stands, it's stored in ./src/template/wasm2c.includes.c which then becomes part of the wasm2c binary itself.

In terms of how they are used, it looks like:

• alloca.h is only needed for exception handling, which are not enabled by default
• math.h is only needed for floating point opcode-supporting functions (like wasm_trunc())
• what is relied on in the other headers should be available everywhere without troubles.

So overall it's looking pretty good.

[1] A C freestanding environment is allowed to only distribute the following headers, which does not contain e.g. math.h: <float.h>, <iso646.h>, <limits.h>, <stdalign.h>, <stdarg.h>, <stdbool.h>, <stddef.h>, <stdint.h>, and <stdnoreturn.h>
https://port70.net/~nsz/c/c11/n1570.html#4p6
The kernel does not even have float.h AFAICT.

[sbc100]

Seems like a worthwhile effort. Sounds like we could start by making the inclusion of math.h and alloca.h conditional? Would you like send a PR for that?

Is there some way to test that we can build in a freestanding environment? i.e. is there some way we can setup such an environment in our CI when we test?

I have to say I'm surprised I didn't know that "freestanding environment" was a thing that was defined by the C standard.. and I've been writing C code for almost 30 years :)

[douglas-raillard-arm]

Sounds like we could start by making the inclusion of math.h and alloca.h conditional?

Indeed.

Would you like send a PR for that?

I'd like to but the nature of the project (assembly, interpreters etc) will unfortunately make it very difficult to obtain legal clearance, but I'm more than happy to test and provide feedback.

Is there some way to test that we can build in a freestanding environment?

gcc and clang have a -ffreestanding option, but they will still link to the libc. #include <stdio.h> will still work since include paths are not affected apparently, and since it links to libc, it will still work. So that makes it rather useless if we want to check we are not relying on libc things.
Linking to libc can be disabled with -nostdlib, but:

• the binary will not work, as it will lack startup code. As a compile check it is ok though.
• but not really ok, since no libc function at all can be used without providing your own implem, not even memcpy().

So as a compile time check, it can be made to work with empty dummy implem of all libc functions relied on. But anything more than compile time is going to be difficult.

I have to say I'm surprised I didn't know that "freestanding environment" was a thing that was defined by the C standard.. and I've been writing C code for almost 30 years :)

TBH there is little use for it unless you work on embedded things, and even then you only care if you try to setup the build system. After all, C was made to write kernels in the first place so it makes sense the spec is not fully assuming a hosted environment.