maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/lld/test/wasm/bsymbolic.s

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

124 lines
4.7 KiB
ArmAsm
Raw Normal View History

[lld][WebAssembly] Add support for -Bsymbolic flag This flag works in a similar way to the ELF linker in that it will resolve any defined symbols to their local definition with a shared library or -pie executable. This flag has no effect on static linking. Differential Revision: https://reviews.llvm.org/D89152
2020-10-08 05:48:37 +08:00
// RUN: llvm-mc -filetype=obj -triple=wasm32-unknown-unknown %s -o %t.o
[lld][WebAssembly] Split __wasm_apply_relocs function in two We have two types of relocations that we apply on startup: 1. Relocations that apply to wasm globals 2. Relocations that apply to wasm memory The first set of relocations use only the `__memory_base` import to update a set of internal globals. Because wasm globals are thread local these need to run on each thread. Memory relocations, like static constructors, must only be run once. To ensure global relocations run on all threads and because the only depend on the immutable `__memory_base` import we can run them during the WebAssembly start functions, instead of waiting until the post-instantiation __wasm_call_ctors. Differential Revision: https://reviews.llvm.org/D93066
2020-12-10 10:14:31 +08:00
// RUN: wasm-ld --no-entry -Bsymbolic %t.o -o %t.wasm 2>&1 | FileCheck -check-prefix=WARNING %s
[lld][WebAssembly] Add support for -Bsymbolic flag This flag works in a similar way to the ELF linker in that it will resolve any defined symbols to their local definition with a shared library or -pie executable. This flag has no effect on static linking. Differential Revision: https://reviews.llvm.org/D89152
2020-10-08 05:48:37 +08:00
// WARNING: warning: -Bsymbolic is only meaningful when combined with -shared
// RUN: wasm-ld --experimental-pic -shared %t.o -o %t0.so
// RUN: obj2yaml %t0.so | FileCheck -check-prefix=NOOPTION %s
// RUN: wasm-ld --experimental-pic -shared -Bsymbolic %t.o -o %t1.so
// RUN: obj2yaml %t1.so | FileCheck -check-prefix=SYMBOLIC %s
[lld][WebAssembly] -Bsymbolic creates indirect function table if needed It can be that while processing relocations, we realize that in the end we need an indirect function table. Ensure that one is present, in that case, to avoid writing invalid object files. Fixes https://bugs.llvm.org/show_bug.cgi?id=49397. Differential Revision: https://reviews.llvm.org/D97843
2021-03-03 18:13:25 +08:00
// NOOPTION: - Type: IMPORT
// NOOPTION-NEXT: Imports:
// NOOPTION-NEXT: - Module: env
// NOOPTION-NEXT: Field: memory
// NOOPTION-NEXT: Kind: MEMORY
// NOOPTION-NEXT: Memory:
[WebAssembly] Rename WasmLimits::Initial to ::Minimum. NFC. This patch renames the "Initial" member of WasmLimits to the name used in the spec, "Minimum". In the core WebAssembly specification, the Limits data type has one required "min" member and one optional "max" member, indicating the minimum required size of the corresponding table or memory, and the maximum size, if any. Although the WebAssembly spec does instantiate locally-defined tables and memories with the initial size being equal to the minimum size, it can't impose such a requirement for imports. It doesn't make sense to require an initial size for a memory import, for example. The compiler can only sensibly express the minimum and maximum sizes. See https://github.com/WebAssembly/js-types/blob/master/proposals/js-types/Overview.md#naming-of-size-limits for a related discussion that agrees that the right name of "initial" is "minimum" when querying the type of a table or memory from JavaScript. (Of course it still makes sense for JS to speak in terms of an initial size when it explicitly instantiates memories and tables.) Differential Revision: https://reviews.llvm.org/D99186
2021-03-23 21:46:32 +08:00
// NOOPTION-NEXT: Minimum: 0x1
[lld][WebAssembly] -Bsymbolic creates indirect function table if needed It can be that while processing relocations, we realize that in the end we need an indirect function table. Ensure that one is present, in that case, to avoid writing invalid object files. Fixes https://bugs.llvm.org/show_bug.cgi?id=49397. Differential Revision: https://reviews.llvm.org/D97843
2021-03-03 18:13:25 +08:00
// NOOPTION-NEXT: - Module: env
// NOOPTION-NEXT: Field: __memory_base
// NOOPTION-NEXT: Kind: GLOBAL
// NOOPTION-NEXT: GlobalType: I32
// NOOPTION-NEXT: GlobalMutable: false
// NOOPTION-NEXT: - Module: env
// NOOPTION-NEXT: Field: __table_base
// NOOPTION-NEXT: Kind: GLOBAL
// NOOPTION-NEXT: GlobalType: I32
// NOOPTION-NEXT: GlobalMutable: false
// NOOPTION-NEXT: - Module: GOT.func
// NOOPTION-NEXT: Field: foo
// NOOPTION-NEXT: Kind: GLOBAL
// NOOPTION-NEXT: GlobalType: I32
// NOOPTION-NEXT: GlobalMutable: true
// NOOPTION-NEXT: - Module: GOT.mem
// NOOPTION-NEXT: Field: bar
// NOOPTION-NEXT: Kind: GLOBAL
// NOOPTION-NEXT: GlobalType: I32
// NOOPTION-NEXT: GlobalMutable: true
// NOOPTION-NEXT: - Type: FUNCTION
[lld][WebAssembly] Add support for -Bsymbolic flag This flag works in a similar way to the ELF linker in that it will resolve any defined symbols to their local definition with a shared library or -pie executable. This flag has no effect on static linking. Differential Revision: https://reviews.llvm.org/D89152
2020-10-08 05:48:37 +08:00
// NOOPTION: - Type: GLOBAL
// NOOPTION-NEXT: Globals:
// NOOPTION-NEXT: - Index: 4
// NOOPTION-NEXT: Type: I32
// NOOPTION-NEXT: Mutable: false
// NOOPTION-NEXT: InitExpr:
// NOOPTION-NEXT: Opcode: I32_CONST
// NOOPTION-NEXT: Value: 0
// NOOPTION-NEXT: - Type: EXPORT
// SYMBOLIC-NOT: - Module: GOT.mem
// SYMBOLIC-NOT: - Module: GOT.func
[lld][WebAssembly] -Bsymbolic creates indirect function table if needed It can be that while processing relocations, we realize that in the end we need an indirect function table. Ensure that one is present, in that case, to avoid writing invalid object files. Fixes https://bugs.llvm.org/show_bug.cgi?id=49397. Differential Revision: https://reviews.llvm.org/D97843
2021-03-03 18:13:25 +08:00
// SYMBOLIC: - Type: IMPORT
// SYMBOLIC-NEXT: Imports:
// SYMBOLIC-NEXT: - Module: env
// SYMBOLIC-NEXT: Field: memory
// SYMBOLIC-NEXT: Kind: MEMORY
// SYMBOLIC-NEXT: Memory:
[WebAssembly] Rename WasmLimits::Initial to ::Minimum. NFC. This patch renames the "Initial" member of WasmLimits to the name used in the spec, "Minimum". In the core WebAssembly specification, the Limits data type has one required "min" member and one optional "max" member, indicating the minimum required size of the corresponding table or memory, and the maximum size, if any. Although the WebAssembly spec does instantiate locally-defined tables and memories with the initial size being equal to the minimum size, it can't impose such a requirement for imports. It doesn't make sense to require an initial size for a memory import, for example. The compiler can only sensibly express the minimum and maximum sizes. See https://github.com/WebAssembly/js-types/blob/master/proposals/js-types/Overview.md#naming-of-size-limits for a related discussion that agrees that the right name of "initial" is "minimum" when querying the type of a table or memory from JavaScript. (Of course it still makes sense for JS to speak in terms of an initial size when it explicitly instantiates memories and tables.) Differential Revision: https://reviews.llvm.org/D99186
2021-03-23 21:46:32 +08:00
// SYMBOLIC-NEXT: Minimum: 0x1
[lld][WebAssembly] -Bsymbolic creates indirect function table if needed It can be that while processing relocations, we realize that in the end we need an indirect function table. Ensure that one is present, in that case, to avoid writing invalid object files. Fixes https://bugs.llvm.org/show_bug.cgi?id=49397. Differential Revision: https://reviews.llvm.org/D97843
2021-03-03 18:13:25 +08:00
// SYMBOLIC-NEXT: - Module: env
// SYMBOLIC-NEXT: Field: __memory_base
// SYMBOLIC-NEXT: Kind: GLOBAL
// SYMBOLIC-NEXT: GlobalType: I32
// SYMBOLIC-NEXT: GlobalMutable: false
// SYMBOLIC-NEXT: - Module: env
// SYMBOLIC-NEXT: Field: __table_base
// SYMBOLIC-NEXT: Kind: GLOBAL
// SYMBOLIC-NEXT: GlobalType: I32
// SYMBOLIC-NEXT: GlobalMutable: false
// SYMBOLIC-NEXT: - Module: env
// SYMBOLIC-NEXT: Field: __indirect_function_table
// SYMBOLIC-NEXT: Kind: TABLE
// SYMBOLIC-NEXT: Table:
// SYMBOLIC-NEXT: Index: 0
// SYMBOLIC-NEXT: ElemType: FUNCREF
// SYMBOLIC-NEXT: Limits:
[WebAssembly] Rename WasmLimits::Initial to ::Minimum. NFC. This patch renames the "Initial" member of WasmLimits to the name used in the spec, "Minimum". In the core WebAssembly specification, the Limits data type has one required "min" member and one optional "max" member, indicating the minimum required size of the corresponding table or memory, and the maximum size, if any. Although the WebAssembly spec does instantiate locally-defined tables and memories with the initial size being equal to the minimum size, it can't impose such a requirement for imports. It doesn't make sense to require an initial size for a memory import, for example. The compiler can only sensibly express the minimum and maximum sizes. See https://github.com/WebAssembly/js-types/blob/master/proposals/js-types/Overview.md#naming-of-size-limits for a related discussion that agrees that the right name of "initial" is "minimum" when querying the type of a table or memory from JavaScript. (Of course it still makes sense for JS to speak in terms of an initial size when it explicitly instantiates memories and tables.) Differential Revision: https://reviews.llvm.org/D99186
2021-03-23 21:46:32 +08:00
// SYMBOLIC-NEXT: Minimum: 0x1
[lld][WebAssembly] -Bsymbolic creates indirect function table if needed It can be that while processing relocations, we realize that in the end we need an indirect function table. Ensure that one is present, in that case, to avoid writing invalid object files. Fixes https://bugs.llvm.org/show_bug.cgi?id=49397. Differential Revision: https://reviews.llvm.org/D97843
2021-03-03 18:13:25 +08:00
// SYMBOLIC-NEXT: - Type: FUNCTION
[lld][WebAssembly] Add support for -Bsymbolic flag This flag works in a similar way to the ELF linker in that it will resolve any defined symbols to their local definition with a shared library or -pie executable. This flag has no effect on static linking. Differential Revision: https://reviews.llvm.org/D89152
2020-10-08 05:48:37 +08:00
// SYMBOLIC: - Type: GLOBAL
// SYMBOLIC-NEXT: Globals:
// SYMBOLIC-NEXT: - Index: 2
// SYMBOLIC-NEXT: Type: I32
// SYMBOLIC-NEXT: Mutable: true
// SYMBOLIC-NEXT: InitExpr:
// SYMBOLIC-NEXT: Opcode: I32_CONST
// SYMBOLIC-NEXT: Value: 0
// SYMBOLIC-NEXT: - Index: 3
// SYMBOLIC-NEXT: Type: I32
// SYMBOLIC-NEXT: Mutable: true
// SYMBOLIC-NEXT: InitExpr:
// SYMBOLIC-NEXT: Opcode: I32_CONST
// SYMBOLIC-NEXT: Value: 0
// SYMBOLIC-NEXT: - Index: 4
// SYMBOLIC-NEXT: Type: I32
// SYMBOLIC-NEXT: Mutable: false
// SYMBOLIC-NEXT: InitExpr:
// SYMBOLIC-NEXT: Opcode: I32_CONST
// SYMBOLIC-NEXT: Value: 0
// SYMBOLIC-NEXT: - Type: EXPORT
.globl foo
foo:
.functype foo () -> ()
end_function
.globl get_foo_address
get_foo_address:
.functype get_foo_address () -> (i32)
global.get foo@GOT
end_function
.globl get_bar_address
get_bar_address:
.functype get_bar_address () -> (i32)
global.get bar@GOT
end_function
.globl bar
.section .data.bar,"",@
bar:
.int 42
.size bar, 4