Skip to content

[WebAssembly] Default export tables with --cooperative-threading #208263

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.

Sign up for GitHub

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

Merged
sbc100 merged 1 commit into from
Aug 6, 2026
Merged

[WebAssembly] Default export tables with --cooperative-threading #208263

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
34 changes: 33 additions & 1 deletion lld/test/wasm/cooperative-threading.s
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@
# thread-context globals (__init_stack_pointer, __init_tls_base, etc.) and
# works without --shared-memory and atomics.

# RUN: llvm-mc -filetype=obj -triple=wasm32-unknown-unknown -o %t.o %s
# RUN: llvm-mc -mattr=+call-indirect-overlong -filetype=obj -triple=wasm32-unknown-unknown -o %t.o %s
# RUN: wasm-ld --cooperative-threading -no-gc-sections -o %t.wasm %t.o
# RUN: obj2yaml %t.wasm | FileCheck %s
# RUN: llvm-objdump -d --no-print-imm-hex --no-show-raw-insn %t.wasm | FileCheck %s --check-prefix=DIS
Expand All @@ -11,12 +11,22 @@
# RUN: not wasm-ld --cooperative-threading --shared-memory %t.o -o %t2.wasm 2>&1 | FileCheck %s --check-prefix=INCOMPAT
# INCOMPAT: --cooperative-threading is incompatible with --shared-memory

.globl __indirect_function_table
.tabletype __indirect_function_table, funcref

.globl __wasm_get_tls_base
__wasm_get_tls_base:
.functype __wasm_get_tls_base () -> (i32)
i32.const 0
end_function

.globl do_call_indirect
do_call_indirect:
.functype do_call_indirect () -> ()
i32.const 1
call_indirect __indirect_function_table, () -> ()
end_function

.globl _start
_start:
.functype _start () -> (i32)
Expand Down Expand Up @@ -66,12 +76,23 @@ foo:
.int8 7
.ascii "atomics"

# CHECK: - Type: TABLE
# CHECK-NEXT: Tables:
# CHECK-NEXT: - Index: 0
# CHECK-NEXT: ElemType: FUNCREF

# Memory must NOT be marked as shared.
# CHECK: - Type: MEMORY
# CHECK-NEXT: Memories:
# CHECK-NEXT: - Minimum: 0x2
# CHECK-NOT: Shared

# The function table is exported by default.
# CHECK: - Type: EXPORT
# CHECK: - Name: __indirect_function_table
# CHECK-NEXT: Kind: TABLE
# CHECK-NEXT: Index: 0

# Only TLS needs a passive data segment; .data stays active and .bss gets no
# segment at all since memory is only instantiated once and starts zeroed.
# CHECK: - Type: DATACOUNT
Expand Down Expand Up @@ -118,3 +139,14 @@ foo:
# DIS-NEXT: i32.load 0
# DIS-NEXT: i32.add
# DIS-NEXT: end

# When the table is imported instead there is no need to also export it.
# RUN: wasm-ld --cooperative-threading --import-table -no-gc-sections -o %t3.wasm %t.o
# RUN: obj2yaml %t3.wasm | FileCheck %s --check-prefix=IMPORT-TABLE

# When the table is imported instead there is no need to also export it.
# IMPORT-TABLE: - Type: IMPORT
# IMPORT-TABLE: - Module: env
# IMPORT-TABLE-NEXT: Field: __indirect_function_table
# IMPORT-TABLE-NEXT: Kind: TABLE
# IMPORT-TABLE-NOT: Kind: TABLE
8 changes: 8 additions & 0 deletions lld/wasm/Driver.cpp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -759,6 +759,14 @@ static void setConfigs() {
if (ctx.arg.sharedMemory)
error("--cooperative-threading is incompatible with --shared-memory");
ctx.arg.libcallThreadContext = true;

// Cooperative threading requires the table is either imported or exported
// or otherwise there's no way for embedders to read spawned functions from
// the table. If we've gotten this far and the table isn't otherwise
// imported (e.g in `isPic` mode) then export the table instead to ensure
// that it's visible to the outside world.
if (!ctx.arg.importTable)
ctx.arg.exportTable = true;

@sbc100 sbc100 Jul 9, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if it would make more sense to do this in the clang driver? Or in the wask-sdk clang driver config file?

Also, couldn't you imagine a scheme which did not involve exporting the table but instead exporting a spawn_fibre function that take a table index itself? i.e. is it really true that the embedder always need to read from the table or can just use function pointers in some cases?

@alexcrichton alexcrichton Jul 10, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought about putting in the driver, yeah, but I feel that here in wasm-ld is the best place. One consequence of a driver is that --export-table as a flag is incompatible with -shared, --import-table, and --relocatable. For all of these flags the driver would have to figure out what's going on and whether --export-table otherwise needs to be passed. Given that I don't think the *.cfg file will work, and while the driver in theory could work it'd also be something I'd have to replicate in rustc, too. Given all that it's how I figured that here in wasm-ld was probably the best place to put this since it's got the most context.

For a different scheme, that's theoretically possible, yeah, but the current definition of the threading intrinsics is that the new-thread intrinsic takes a table + index and spawns the thread based on that. This is intended to be somewhat future-compatible with a world where an intrinsic takes a funcref directly, but that's not possible to call from C right now hence the interim table+index intrinsic.

@sbc100 sbc100 Jul 10, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, yes I the driver would need more smarts in that case to avoid adding --export-table when it shouldn't.

I'm not convinced the linker should be charge or implementing the specifics of the wasi scheme like this, but maybe its the only good option in this case.

On the other hand is it too late to reconsider how fibers are launched in the pre-funcref world. Wouldn't calling start_fibre_indirect be better some ways (since it would avoid exposing the entire table to host)?

@alexcrichton alexcrichton Jul 10, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Coop threading hasn't shipped yet so it's still possible to change details like this, but personally I'd say that this is the next-best design before a true funcref-like design. I'd prefer, for example, to call an imported function with a funcref parameter ("go run this in a thread") as the desired end state which would also keep the table entirely encapsulated.

If you'd like though I can file an issue on WebAssembly/component-model and cc you on that for discussion, too.

}
}

Expand Down