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

Question: The correct way to compile without main function #110

Closed
timonson opened this issue Mar 25, 2020 · 5 comments
Closed

Question: The correct way to compile without main function #110

timonson opened this issue Mar 25, 2020 · 5 comments

Comments

@timonson
Copy link

Hi guys, I would like to create a WASM file from the following C file:

int total_count = 0;

// Modules can have state
int count() {
  return ++total_count;
}

// They can do work
int add(int a, int b) {
  return a + b;
}

// But they only work with numbers
char * string() {
  return "Hello, world!";
}

Besides other things, I tried to run $WASI_SDK_DIR/bin/clang --target=wasm32-unknown-wasi -Wl,--no-entry -nostartfiles --sysroot $WASI_SDK_DIR/share/wasi-sysroot -o module.wasm module.c. This command creates a module.wasm file without compiler error but the file is almost empty unfortunately.

My goal is to create an equal file with wasi-sdk to what the following command does: clang --target=wasm32 --no-standard-libraries -Wl,--export-all -Wl,--no-entry -o module.wasm module.c

I don't need a main function because I want to import these functions as ES Modules later with the help from deno.

What am I doing wrong?
Thank you!

@sbc100
Copy link
Member

sbc100 commented Mar 26, 2020

Currently WASI only supports programs with main functions. See WebAssembly/WASI#13 for the plan to extend this.

Having said that there are various ways to achieve what you want in a non-standards-conforming way today.

I would still recommend keeping an empty main function around if only to ensure that all the correct startup functions are called. For example the _start function that calls main is also in charge of calling things like C++ constructor (you can do this youself by calling __wasm_call_ctors if you prefer).

In terms of exporting functions probably the best way is to use the __attribute__((export_name)) clang attribute to tag the functions you want to export and the name you want to export them under.
I would also have though the --export command line flag should work too. Is it not working for you?

@timonson
Copy link
Author

Hi @sbc100 thank you a lot. I could make it work with the --export-all flag thanks to your advice.

kildom pushed a commit to kildom/clang-wasi-port that referenced this issue Jul 14, 2021
wasi-libc's copy of libpreopen has evolved so many local changes that
it's no longer worth keeping the upstream code structure and marking
changes with __wasilibc_unmodified_upstream.

This PR merges the source files into a single file, removes all
__wasilibc_unmodified_upstream code, eliminates the ability to
allocate multiple preopen lists, eliminates the need for
__wasilibc_init_preopen, eliminates the non-standard eaccess, and
makes several other cleanups. It also enables NDEBUG so that internal
assertions are disabled in release builds.
@mmathys
Copy link

mmathys commented Jul 15, 2022

For anyone looking at this in the future, I made it work like this:

__attribute__((export_name("entry")))
int entry(int argc, char **argv) {
...
}

compile using

clang -Wl,--no-entry -mexec-model=reactor -o example.wasm example.c

using clang from the WASI-SDK.

@sbc100
Copy link
Member

sbc100 commented Jul 15, 2022

You shouldn't need to define a dummy main like that. I think the link flag you want is -mexec-model=reactor

@mmathys
Copy link

mmathys commented Jul 15, 2022

Thanks! Updated the example.

alexcrichton pushed a commit to alexcrichton/wasi-sdk that referenced this issue Apr 5, 2023
This brings in the following changes:

f645f49 Update signal macros after upgrade to snapshot1 (WebAssembly#144)
8b3266d github actions: pin checkout action to v1 (WebAssembly#145)
410c660 Use constructor functions for optional init routines. (WebAssembly#142)
fe13053 c header generation updated for reorganized witx ast (WebAssembly#139)
cd74e1d Correct the version of WebAssembly#136 on master (WebAssembly#141)
446cb3f Wasi snapshot preview1 (WebAssembly#140)
54102f0 Ignore rights in libpreopen. (WebAssembly#129)
8c9e1c6 Make the `__original_main` definition weak, fixing -flto. (WebAssembly#138)
cf81683 Optimize `fmin`, `fmax`, etc. (WebAssembly#120)
deb8eae Don't pre-check capabilities in `openat`. (WebAssembly#130)
ca9046d Use consistent style for wasi-libc C source files. (WebAssembly#131)
951cc3e Fix unintended recursion in __wasilibc_register_preopened_fd. (WebAssembly#133)
5216983 Avoid a `strdup` call in `__wasilibc_populate_libpreopen`. (WebAssembly#128)
70099d4 Don't link in libpreopen initialization code when it isn't needed. (WebAssembly#127)
ec4549d Temporarily disable the use of `__heap_base`. (WebAssembly#132)
a214f1c Use __heap_base by dlmalloc (WebAssembly#114)
a94d2d0 Avoid varargs conventions when calling open (WebAssembly#126)
7fcc4f2 Revamp and simplify the libpreopen code. (WebAssembly#110)
eb7230c Remove more unsupported headers. (WebAssembly#123)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants