2019-03-30 04:43:49 +08:00
# RUN: yaml2obj %s -o %t1.o
# RUN: wasm-ld --no-entry %t1.o -o - | obj2yaml | FileCheck %s --check-prefix NO-SHARED
# RUN: not wasm-ld --no-entry --shared-memory --max-memory=131072 %t1.o -o - 2>&1 | FileCheck %s --check-prefix SHARED
--- !WASM
FileHeader :
Version : 0x00000001
Sections :
- Type : IMPORT
Imports :
- Module : env
Field : __linear_memory
Kind : MEMORY
Memory :
2021-03-23 21:46:32 +08:00
Minimum : 0x00000001
2019-03-30 04:43:49 +08:00
- Module : env
Field : __indirect_function_table
Kind : TABLE
Table :
2020-10-13 22:13:10 +08:00
Index : 0
2019-03-30 04:43:49 +08:00
ElemType : FUNCREF
Limits :
2021-03-23 21:46:32 +08:00
Minimum : 0x00000000
2019-03-30 04:43:49 +08:00
- Type : DATA
Segments :
- SectionOffset : 6
InitFlags : 0
Offset :
Opcode : I32_CONST
Value : 0
Content : 68656C6C6F0A00
- Type : CUSTOM
Name : linking
Version : 2
SymbolTable :
- Index : 0
Kind : DATA
Name : hello_str
Flags : [ ]
Segment : 0
Size : 7
SegmentInfo :
- Index : 0
Name : .rodata.hello_str
Alignment : 0
Flags : [ ]
- Type : CUSTOM
Name : target_features
Features :
- Prefix : DISALLOWED
[WebAssembly] Disallow 'shared-mem' rather than 'atomics'
Summary:
The WebAssembly backend automatically lowers atomic operations and TLS
to nonatomic operations and non-TLS data when either are present and
the atomics or bulk-memory features are not present, respectively. The
resulting object is no longer thread-safe, so the linker has to be
told not to allow it to be linked into a module with shared
memory. This was previously done by disallowing the 'atomics' feature,
which prevented any objct with its atomic operations or TLS removed
from being linked with any object containing atomics or TLS, and
therefore preventing it from being linked into a module with shared
memory since shared memory requires atomics.
However, as of https://github.com/WebAssembly/threads/issues/144, the
validation rules are relaxed to allow atomic operations to validate
with unshared memories, which makes it perfectly safe to link an
object with stripped atomics and TLS with another object that still
contains TLS and atomics as long as the resulting module has an
unshared memory. To allow this kind of link, this patch disallows a
pseudo-feature 'shared-mem' rather than 'atomics' to communicate to
the linker that the object is not thread-safe. This means that the
'atomics' feature is available to accurately reflect whether or not an
object has atomics enabled.
As a drive-by tweak, this change also requires that bulk-memory be
enabled in addition to atomics in order to use shared memory. This is
because initializing shared memories requires bulk-memory operations.
Reviewers: aheejin, sbc100
Subscribers: dschuff, jgravelle-google, hiraditya, sunfish, jfb, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D79542
2020-05-07 10:33:24 +08:00
Name : "shared-mem"
2019-03-30 04:43:49 +08:00
...
# NO-SHARED: - Type: MEMORY
# NO-SHARED-NEXT: Memories:
2021-03-23 21:46:32 +08:00
# NO-SHARED-NEXT: - Minimum: 0x2
2019-03-30 04:43:49 +08:00
# NO-SHARED-NOT: Maximum:
[WebAssembly] Disallow 'shared-mem' rather than 'atomics'
Summary:
The WebAssembly backend automatically lowers atomic operations and TLS
to nonatomic operations and non-TLS data when either are present and
the atomics or bulk-memory features are not present, respectively. The
resulting object is no longer thread-safe, so the linker has to be
told not to allow it to be linked into a module with shared
memory. This was previously done by disallowing the 'atomics' feature,
which prevented any objct with its atomic operations or TLS removed
from being linked with any object containing atomics or TLS, and
therefore preventing it from being linked into a module with shared
memory since shared memory requires atomics.
However, as of https://github.com/WebAssembly/threads/issues/144, the
validation rules are relaxed to allow atomic operations to validate
with unshared memories, which makes it perfectly safe to link an
object with stripped atomics and TLS with another object that still
contains TLS and atomics as long as the resulting module has an
unshared memory. To allow this kind of link, this patch disallows a
pseudo-feature 'shared-mem' rather than 'atomics' to communicate to
the linker that the object is not thread-safe. This means that the
'atomics' feature is available to accurately reflect whether or not an
object has atomics enabled.
As a drive-by tweak, this change also requires that bulk-memory be
enabled in addition to atomics in order to use shared memory. This is
because initializing shared memories requires bulk-memory operations.
Reviewers: aheejin, sbc100
Subscribers: dschuff, jgravelle-google, hiraditya, sunfish, jfb, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D79542
2020-05-07 10:33:24 +08:00
# SHARED: --shared-memory is disallowed by {{.*}}shared-memory-no-atomics.yaml.tmp1.o because it was not compiled with 'atomics' or 'bulk-memory' features.
