Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: Wasm Proposal Details at Compile and Runtime #3980

Open
woodsmc opened this issue Dec 22, 2024 · 0 comments
Open

Feature Request: Wasm Proposal Details at Compile and Runtime #3980

woodsmc opened this issue Dec 22, 2024 · 0 comments
Labels
new feature New feature request

Comments

@woodsmc
Copy link
Contributor

woodsmc commented Dec 22, 2024

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 lum1n0us added the new feature New feature request label Dec 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
new feature New feature request
Projects
None yet
Development

No branches or pull requests

2 participants