Rust cdylib · rust-toolchain · Zulip Chat Archive

Stream: rust-toolchain

Topic: Rust cdylib

Dan Gohman (Mar 04 2024 at 23:47):

In C:

-shared means to produce a shared-everything dynamic library (with a dylink.0, PIC, imported memory, etc.)
-mexec-model=reactor means to produce a "reactor-style" Wasm module (no dylink.0, no PIC, exported memory, etc.).

In Rust:

cdylib means to produce a "reactor-style" Wasm module
there is no way to produce a shared-everything dynamic library (AFAICT)

Should we be thinking about a plan to add shared-everything dynamic linking support for Rust? I don't know of anyone that urgently needs it, but if we will eventually need it, perhaps we should start thinking about how we'll get there?

Alex Crichton (Mar 04 2024 at 23:50):

I think it'd be fine to redefine cdylib on the wasm32-wasip2 target and beyond, but beyond that I don't know of a great way to deal with -mexec-model.

The closest equivalent I can think of is #![windows_subsystem = "..."] at the crate level

Dan Gohman (Mar 04 2024 at 23:52):

How hard would it be to add a new crate-type?

Joel Dice (Mar 04 2024 at 23:55):

Dan Gohman said:

...

there is no way to produce a shared-everything dynamic library (AFAICT)

Should we be thinking about a plan to add shared-everything dynamic linking support for Rust? I don't know of anyone that urgently needs it, but if we will eventually need it, perhaps we should start thinking about how we'll get there?

You can do it today with some black magic, e.g.: RUSTFLAGS="-C relocation-model=pic" cargo +nightly build -Zbuild-std=panic_abort,std --release --target=wasm32-wasi and crate-type = [ "staticlib" ] to build a PIC .a file, which you can then run through clang -shared -Wl,--whole-archive <name>.a --Wl,--no-whole-archive. What could be easier? :)

Joel Dice (Mar 04 2024 at 23:57):

Just making "-C relocation-model=pic" the default for wasm32-wasip2 would be a big step forward

Dan Gohman (Mar 04 2024 at 23:58):

To do even that though, we should have something to migrate existing users to.

Alex Crichton (Mar 04 2024 at 23:59):

I suspect adding a new crate type would be a very big ask

Alex Crichton (Mar 04 2024 at 23:59):

that's integrated in tons and tons of rust tooling

Alex Crichton (Mar 04 2024 at 23:59):

alternatively we could make #![no_main] work for executables perhaps

Alex Crichton (Mar 05 2024 at 00:00):

to map to the "reactor" case

Dan Gohman (Mar 05 2024 at 00:00):

Ooh, that's an interesting idea.

Dan Gohman (Mar 05 2024 at 00:28):

Hmm, no_start means something subtly different on other architectures. It looks like what we might want is the #![no_entry] proposal.

RFC: Add `no_entry` attribute to omit entry point symbol by joshtriplett · Pull Request #2735 · rust-lang/rfcs

This allows people to write their own entry point, without needing to manually link or create a .cargo/config with target-specific linker arguments.

Alex Crichton (Mar 05 2024 at 00:38):

it might be best to have #![wasm_something = "something"] perhaps to sidestep portability concerns

Alex Crichton (Mar 05 2024 at 00:38):

we don't really want to force any other platform to worry about this

Alex Crichton (Mar 05 2024 at 00:39):

I'm not sure if we want to persist the "command" and "reactor" terminology though?

Alex Crichton (Mar 05 2024 at 00:39):

perhaps #![wasm_no_start] on the crate

Dan Gohman (Mar 05 2024 at 00:39):

Yeah, I was never a huge fan of "reactor", and would be happy to use some other term.

Alex Crichton (Mar 05 2024 at 00:40):

with wasm_no_start we perhaps wouldn't have to give it a name even

Alex Crichton (Mar 05 2024 at 00:40):

it's all just wasm binaries with or without a start

Dan Gohman (Mar 05 2024 at 00:42):

What about #![wasm_exec = "exports"], which is sort of short for "the way you execute the code is, you call the exports"?

Alex Crichton (Mar 05 2024 at 01:40):

I like the idea of the terminology, but reading #![wasm_exec = "exports"] as a standalone thing doesn't do a great job of conveying that, so we might want some wordsmithing there