Stream: git-wasmtime

Topic: wasmtime / issue #5996 Generating executable entrypoints ...


view this post on Zulip Wasmtime GitHub notifications bot (Mar 11 2023 at 21:56):

a-nick-fischer opened issue #5996:

Feature

As far as I can tell, there's no build-in way to generate an entrypoint (_start) when generating an object file using cranelift-object. Please correct me if I'm mistaken, but I think this makes it impossible to actually produce a properly executable file using only cranelift and a linker.

Two solutions came to my mind:

Note: I tried defining _start as a function which obviously didn't work out.

Benefit

Being able to actually generate runnable executables with cranelift-object.

Implementation

I'm definitely not qualified to fill this section in :P

Alternatives

Some alternative approaches come to mind:

view this post on Zulip Wasmtime GitHub notifications bot (Mar 11 2023 at 22:05):

bjorn3 commented on issue #5996:

cranelift-object only produces object files. You need to link them yourself to get an executable or dynamic library. If you link you will either have to provide the right crt.o to define the _start function or you have gcc/clang provide it for you. cranelift-object can't know what the right contents are. On some systems it calls __libc_start_main, on others it calls the constrictors and directly jumps to main and on yet other systems it does low level hardware initialization and sets up a stack before calling main.

I did just recommend defining main and then using gcc or clang to link the executable.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 11 2023 at 22:06):

bjorn3 edited a comment on issue #5996:

cranelift-object only produces object files. You need to link them yourself to get an executable or dynamic library. If you link you will either have to provide the right crt.o to define the _start function or you have gcc/clang provide it for you. cranelift-object can't know what the right contents are. On some systems it calls __libc_start_main, on others it calls the constrictors and directly jumps to main and on yet other systems it does low level hardware initialization and sets up a stack before calling main.

I did just recommend defining main and then using gcc or clang to link the executable. This is what rustc_codegen_cranelift does too.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 11 2023 at 22:24):

a-nick-fischer commented on issue #5996:

Alright I see. I'll be going with the gcc solution then too

view this post on Zulip Wasmtime GitHub notifications bot (Mar 11 2023 at 22:24):

a-nick-fischer closed issue #5996:

Feature

As far as I can tell, there's no build-in way to generate an entrypoint (_start) when generating an object file using cranelift-object. Please correct me if I'm mistaken, but I think this makes it impossible to actually produce a properly executable file using only cranelift and a linker.

Two solutions came to my mind:

Note: I tried defining _start as a function which obviously didn't work out.

Benefit

Being able to actually generate runnable executables with cranelift-object.

Implementation

I'm definitely not qualified to fill this section in :P

Alternatives

Some alternative approaches come to mind:


Last updated: Dec 23 2024 at 12:05 UTC