Feature Request: Wasm Proposal Details at Compile and Runtime

[woodsmc]

As requested by @loganek creating a new feature to track this improvement

Feature

Compile Time

At compile time a list of the features enabled and the features not-enabled are displayed to the user.

Runtime Help

At runtime the iwasm tool can list the features it has enabled and the features which are not enabled with -v or with --help

Runtime Failure Improvement

The main result of a feature miss match between a .wasm file and the runtime is a parsing error. When a parsing error occurs WAMR should output the list of features it has enabled and ask the user to check that this matches the feature enabled by the compiler that produced the .wasm file.

Community Suggestion

We could suggest to the compiler / tool chain folks that they think about including a custom section with a list of the features enabled by the compiler when the .wasm file was produced. It would be easy to remove this custom section to reduce binary size, but it would provide useful information to the user.

Benefit

Different languages and compiler tool chains are changing the feature sets they use by default. This results in users compiling their application to Wasm and seeing error messages when attempting to execute them. The error messages are confusing and often cause hours of debugging by Wamr users. e.g.

• Compiling without references -> error message about expecting a zero byte
• Compiling without exception handling -> error message about an unknown type section

Displaying the sets of features which are enabled and disabled is a quick way to allow the user identify the issue themselves.

Implementation

There are a set of features enabled for all platforms and set of features enabled for specific platforms so it is not always clear for new users when switching between platforms.

Alternatives

TODO: What are the alternative implementation approaches or alternative ways to
solve the problem that this feature would solve? How do these alternatives
compare to this proposal?

To Keep the Conversation Going from #3978

          > > Mentioning the options selected during the build process - and the options not selected would be really great improvement.

AFAIK some of the options are printed when generating CMake file, but some of them are not. Also, it'd be good to print the enabled features when user calls iwasm --help or iwasm -v. Would you mind open an issue so we can track the improvement?

I am creating a new document about which wasm proposals are on-by-default and which are off-by-default. Are you suggesting we should output something like that during cmake configuration and execution by iwasm ?

Might need to add the library case

Originally posted by @lum1n0us in #3978 (comment)

[lum1n0us]

I have created a #3989 for further discussion.

[loganek]

We could suggest to the compiler / tool chain folks that they think about including a custom section with a list of the features enabled by the compiler when the .wasm file was produced. It would be easy to remove this custom section to reduce binary size, but it would provide useful information to the user.

Not sure if that's needed. Is there any feature that's currently not detectable?

[lum1n0us]

From my perspective, it's a method to inform users about the combination of features they are currently using and to confirm whether it aligns with their expectations, rather than to trace back through the build environment.

[loganek]

From my perspective, it's a method to inform users about the combination of features they are currently using and to confirm whether it aligns with their expectations, rather than to trace back through the build environment.

Right, in that case I think it makes sense to have the custom section as suggested by @woodsmc

[woodsmc]

Yeah, speaking from personal experience, there has been a bunch of times where I've compiled code to .wasm, and discovered it won't execute in the host environment. I have spent hours trying to debug this, only to discover that the .wasm needed features which were not turned on in the host environment.

Anything that helps identify this would be amazing. - The reason why I'm suggesting to reach out to the WASI-SDK folks is that I think they are already inserting a lot of additional information in the .wasm file already. This also seems to be growing. If you check the compiler output for WASI-SDK 21 and compare it to WASI-SDK 25 you can see that the same code results in a much larger .wasm file. For example, a simple "Hello World" example compiles with (-O3) to 4.5kb using wasi-sdk 21, but compiles to a much larger 49kb using wasi-sdk 25. It looks like it's adding 9 custom sections with a lot of debug information.

Edit:
Having the custom section, so that the runtime could immediately identify that a feature required by the .wasm isn't available in the current runtime would help. Hugely - saving hours of debug time.

[yamt]

We could suggest to the compiler / tool chain folks that they think about including a custom section with a list of the features enabled by the compiler when the .wasm file was produced. It would be easy to remove this custom section to reduce binary size, but it would provide useful information to the user.

you can check the existing target_features section if you want.

[yamt]

If you check the compiler output for WASI-SDK 21 and compare it to WASI-SDK 25 you can see that the same code results in a much larger .wasm file. For example, a simple "Hello World" example compiles with (-O3) to 4.5kb using wasi-sdk 21, but compiles to a much larger 49kb using wasi-sdk 25. It looks like it's adding 9 custom sections with a lot of debug information.

it's mainly because wasi-sdk has turned on the debug info.
it's recommended to strip your binary if the size matters.

[loganek]

Yeah, speaking from personal experience, there has been a bunch of times where I've compiled code to .wasm, and discovered it won't execute in the host environment.

Could you give some more-concrete examples? I think in most (all?) cases we should be able to provide a meaningful error message to the user, even if the "features" section does not exist (e.g. similarly to what we did in #4000 for the reference types)