Coredumps: how to represent process/posix-y info like executable name, arguments, and environment

[fitzgen]

Wasm itself doesn't have these concepts. The closest thing it has to a process is the store.

This impedance mismatch is visible when looking at a collection of Wasm instances running in a Web browser:

• Which instance is "the" executable and therefore its module name should be used as the executable name?
• What are the process arguments? This concept doesn't exist except in tools that layer a posix-y facade on top of the Web, like (IIUC) Emscripten can.
• Ditto for environment variables.

WASI, however, does have these concepts, so it makes sense that a WASI-specific coredump section (or sections) add this information. But I don't think it makes sense to put this info in the fully-general, core-Wasm part of the coredump spec.

@xtuc, what do you think of splitting this info out to an optional WASI-specific coredump section(s)?

[sbc100]

I believe the name section allows the name of the module to be specified so that might make sense for the executable name, when it is present.

[fitzgen]

the name of the module

The catch is that there are potentially N instances of M modules in the store when we captured the coredump (see #207) and the name section only talks about the current Wasm module (which is the coredump file itself).

We could rely on each referenced module's name section for each module's name (although this requires access to those modules, which isn't guaranteed, and creates a chicken-and-egg problem unless we copy each module inline into the coredump file itself).

And because we can have multiple instances and modules, it isn't clear which one is "the" executable.

[sbc100]

That sounds roughly analogous to the ELF world where a given process will have any number of ELF files mapped into address space, perhaps? One can even imagine the same ELF mapped more then once in different places.

[fitzgen]

Yep, totally.