Support multithreading #388
Labels
C-enhancement
Category: An issue proposing an enhancement or a PR with one.
Comments
bjorn3
added
the
C-enhancement
|
This would also require TLS support. (not the protocol, but thread-local storage) Edit: opened bytecodealliance/cranelift#963 |
|
I am interested in adding TLS support to the |
|
Sure @philipc. |
|
https://github.com/bjorn3/rustc_codegen_cranelift/tree/wip_tls contains a test for tls support. |
#![feature(thread_local)]
#[thread_local]
static mut A: u8 = 42;
pub unsafe fn __get_it() -> *mut u8 {
&mut A
}$ rustc --crate-type lib tls.rs -Ccodegen-units=1 -Clto=no -O --emit obj,llvm-ir; ModuleID = 'tls.3a1fbbbh-cgu.0'
source_filename = "tls.3a1fbbbh-cgu.0"
target datalayout = "e-m:o-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-apple-macosx10.7.0"
@_ZN3tls1A17h13af140b93a46e97E = internal thread_local global <{ [1 x i8] }> <{ [1 x i8] c"*" }>, section "__DATA,__thread_data", align 1
; tls::__get_it
; Function Attrs: norecurse nounwind readnone uwtable
define i8* @_ZN3tls8__get_it17h59d6925afa6bde3cE() unnamed_addr #0 {
start:
ret i8* getelementptr inbounds (<{ [1 x i8] }>, <{ [1 x i8] }>* @_ZN3tls1A17h13af140b93a46e97E, i64 0, i32 0, i64 0)
}
attributes #0 = { norecurse nounwind readnone uwtable "no-frame-pointer-elim"="true" "probe-stack"="__rust_probestack" "target-cpu"="core2" }Generated asm, relocations and sectionsMacOSDisassembly of section __TEXT,__text:
__ZN3tls8__get_it17h59d6925afa6bde3cE:
0: 55 pushq %rbp
1: 48 89 e5 movq %rsp, %rbp
4: 48 8b 3d 00 00 00 00 movq (%rip), %rdi
0000000000000007: X86_64_RELOC_TLV __ZN3tls1A17h13af140b93a46e97E@TLVP
b: ff 17 callq *(%rdi)
d: 5d popq %rbp
e: c3 retq
Disassembly of section __DATA,__thread_data:
__ZN3tls1A17h13af140b93a46e97E$tlv$init:
f: 2a <unknown>
Disassembly of section __DATA,__thread_vars:
__ZN3tls1A17h13af140b93a46e97E:
10: 00 00 addb %al, (%rax)
0000000000000010: X86_64_RELOC_UNSIGNED __tlv_bootstrap
12: 00 00 addb %al, (%rax)
14: 00 00 addb %al, (%rax)
16: 00 00 addb %al, (%rax)
18: 00 00 addb %al, (%rax)
1a: 00 00 addb %al, (%rax)
1c: 00 00 addb %al, (%rax)
1e: 00 00 addb %al, (%rax)
20: 00 00 addb %al, (%rax)
0000000000000020: X86_64_RELOC_UNSIGNED __ZN3tls1A17h13af140b93a46e97E$tlv$init
22: 00 00 addb %al, (%rax)
24: 00 00 addb %al, (%rax)
26: 00 00 addb %al, (%rax)LinuxDisassembly of section .text._ZN3tls8__get_it17h59d6925afa6bde3cE:
_ZN3tls8__get_it17h59d6925afa6bde3cE:
0: 50 pushq %rax
1: 48 8d 3d 00 00 00 00 leaq (%rip), %rdi
0000000000000004: R_X86_64_TLSLD _ZN3tls1A17h13af140b93a46e97E-4
8: e8 00 00 00 00 callq 0 <_ZN3tls8__get_it17h59d6925afa6bde3cE+0xd>
0000000000000009: R_X86_64_PLT32 __tls_get_addr-4
d: 48 8d 80 00 00 00 00 leaq (%rax), %rax
0000000000000010: R_X86_64_DTPOFF32 _ZN3tls1A17h13af140b93a46e97E
14: 59 popq %rcx
15: c3 retq
Disassembly of section .rela.text._ZN3tls8__get_it17h59d6925afa6bde3cE:
.rela.text._ZN3tls8__get_it17h59d6925afa6bde3cE:
0: 04 00 addb $0, %al
2: 00 00 addb %al, (%rax)
4: 00 00 addb %al, (%rax)
6: 00 00 addb %al, (%rax)
8: 14 00 adcb $0, %al
a: 00 00 addb %al, (%rax)
c: 02 00 addb (%rax), %al
e: 00 00 addb %al, (%rax)
10: fc cld
11: ff ff <unknown>
13: ff ff <unknown>
15: ff ff <unknown>
17: ff 09 decl (%rcx)
19: 00 00 addb %al, (%rax)
1b: 00 00 addb %al, (%rax)
1d: 00 00 addb %al, (%rax)
1f: 00 04 00 addb %al, (%rax,%rax)
22: 00 00 addb %al, (%rax)
24: 05 00 00 00 fc addl $4227858432, %eax
29: ff ff <unknown>
2b: ff ff <unknown>
2d: ff ff <unknown>
2f: ff 10 callq *(%rax)
31: 00 00 addb %al, (%rax)
33: 00 00 addb %al, (%rax)
35: 00 00 addb %al, (%rax)
37: 00 15 00 00 00 02 addb %dl, 33554432(%rip)
3d: 00 00 addb %al, (%rax)
3f: 00 00 addb %al, (%rax)
41: 00 00 addb %al, (%rax)
43: 00 00 addb %al, (%rax)
45: 00 00 addb %al, (%rax)
47: 00 <unknown>
Disassembly of section .tdata._ZN3tls1A17h13af140b93a46e97E:
_ZN3tls1A17h13af140b93a46e97E:
0: 2a <unknown> |
|
@bjorn3 Which tool did you use to dump the object file info? Generated object for Windows x86-64
Disassembly of section .text:
0000000000000000 _ZN3tls8__get_it17h59d6925afa6bde3cE:
0: 8b 05 00 00 00 00 movl (%rip), %eax
0000000000000002: IMAGE_REL_AMD64_REL32 _tls_index
6: 65 48 8b 0c 25 58 00 00 00 movq %gs:88, %rcx
f: 48 8b 04 c1 movq (%rcx,%rax,8), %rax
13: 48 8d 80 00 00 00 00 leaq (%rax), %rax
0000000000000016: IMAGE_REL_AMD64_SECREL _ZN3tls1A17h13af140b93a46e97E
1a: c3 retq
Disassembly of section .tls$:
0000000000000000 _ZN3tls1A17h13af140b93a46e97E:
0: 2a <unknown> |
|
|
I found documentation for ELF TLS: https://akkadia.org/drepper/tls.pdf |
7 tasks
|
Opened wip pr bytecodealliance/cranelift#1174 for ELF TLS. |
|
Note that making variable |
|
When combining with bytecodealliance/cranelift#1174 and gimli-rs/object#139, the |
|
The latest commit to the |
|
@philipc According to https://docs.microsoft.com/en-us/windows/win32/debug/pe-format, TLS needs to load a value from |
|
It's different for i686 vs x86-64 Generated object for Windows i686
|
|
That explains it. |
Merged
|
It's also different for Windows versus Linux. Linux uses gs for TLS on 32-bit and fs on 64-bit. Windows uses fs for TLS on 32-bit and (I think) gs on 64-bit. So this isn't just architecture specific, it's also platform specific, and we need to match the platform convention. (Also, very important: on Windows, you're supposed to call a function in a Windows DLL to get TLS, and not access the register itself; Windows reserves the right to change the convention. Linux treats its convention as ABI.) |
|
The TLS PR uses a flag to determine the way TLS is implemented. It doesn't use |
@joshtriplett In the Windows disassemblies I gave above it is using |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently atomics are not atomic.
Blocked on https://github.com/CraneStation/cranelift/issues/582
The text was updated successfully, but these errors were encountered: