Stream: git-wasmtime

Topic: wasmtime / Issue #1885 [Cranelift] Add COFF TLS support

view this post on Zulip Wasmtime GitHub notifications bot (Jun 16 2020 at 10:12):

bjorn3 opened Issue #1885:

Feature

Support TLS data objects with COFF binaries.

Benefit

TLS data objects are already supported for ELF and Mach-O binaries.

Implementation

Add a new x86_coff_tls_get_addr instruction. See https://github.com/bjorn3/rustc_codegen_cranelift/issues/388#issuecomment-532930282 for what x86_64 instructions to lower the x86_coff_tls_get_addr instruction to. Then make changes to the object crate as necessary to generate TLS sections for COFF.

Alternatives

N/A

view this post on Zulip Wasmtime GitHub notifications bot (Jun 29 2020 at 15:53):

bnjbvr labeled Issue #1885:

Feature

Support TLS data objects with COFF binaries.

Benefit

TLS data objects are already supported for ELF and Mach-O binaries.

Implementation

Add a new x86_coff_tls_get_addr instruction. See https://github.com/bjorn3/rustc_codegen_cranelift/issues/388#issuecomment-532930282 for what x86_64 instructions to lower the x86_coff_tls_get_addr instruction to. Then make changes to the object crate as necessary to generate TLS sections for COFF.

Alternatives

N/A

view this post on Zulip Wasmtime GitHub notifications bot (Jun 29 2020 at 15:53):

github-actions[bot] commented on Issue #1885:

Subscribe to Label Action

cc @bnjbvr

<details>
This issue or pull request has been labeled: "cranelift"

Thus the following users have been cc'd because of the following labels:

To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.

Learn more.
</details>

view this post on Zulip Wasmtime GitHub notifications bot (May 06 2021 at 08:01):

XAMPPRocky commented on Issue #1885:

Commenting to note that at the moment, COFF support is the primary blocker to compiling Rust projects like tokei with cg_clif on Windows MSVC.

view this post on Zulip Wasmtime GitHub notifications bot (May 06 2021 at 08:14):

cfallin commented on Issue #1885:

Thanks for the tracking issue @XAMPPRocky!

This one probably isn't too bad, if you (or another adventurous soul) wants to take a look: I believe it should work similarly to the ELF case, in which we emit a pre-ordained sequence of instructions that the linker recognizes and can fix up. Then we emit that pseudoinst for the sequence based on the TlsModel during lowering. I don't have an MSVC setup handy to work on this but I'm happy to review a PR! :-)

view this post on Zulip Wasmtime GitHub notifications bot (May 06 2021 at 08:16):

cfallin edited a comment on Issue #1885:

Thanks for the note @XAMPPRocky!

This one probably isn't too bad, if you (or another adventurous soul) wants to take a look: I believe it should work similarly to the ELF case, in which we emit a pre-ordained sequence of instructions that the linker recognizes and can fix up. Then we emit that pseudoinst for the sequence based on the TlsModel during lowering. I don't have an MSVC setup handy to work on this but I'm happy to review a PR! :-)

view this post on Zulip Wasmtime GitHub notifications bot (May 06 2021 at 08:46):

XAMPPRocky commented on Issue #1885:

I have a setup available, but I'll admit to being quite out of my depth in terms of writing the assembly, so I could make the PR with some guidance. The steps are relatively straight forward, but I'm not sure how to map that to instructions. For example how do you access a special variable like __tls_used?

Executable code accesses a static TLS data object through the following steps:

  1. At link time, the linker sets the Address of Index field of the TLS directory. This field points to a location where the program expects to receive the TLS index.

  2. The Microsoft run-time library facilitates this process by defining a memory image of the TLS directory and giving it the special name "__tls_used" (Intel x86 platforms) or "_tls_used" (other platforms). The linker looks for this memory image and uses the data there to create the TLS directory. Other compilers that support TLS and work with the Microsoft linker must use this same technique.

  3. When a thread is created, the loader communicates the address of the thread's TLS array by placing the address of the thread environment block (TEB) in the FS register. A pointer to the TLS array is at the offset of 0x2C from the beginning of TEB. This behavior is Intel x86-specific.

  4. The loader assigns the value of the TLS index to the place that was indicated by the Address of Index field.

  5. The executable code retrieves the TLS index and also the location of the TLS array.

  6. The code uses the TLS index and the TLS array location (multiplying the index by 4 and using it as an offset to the array) to get the address of the TLS data area for the given program and module. Each thread has its own TLS data area, but this is transparent to the program, which does not need to know how data is allocated for individual threads.

  7. An individual TLS data object is accessed as some fixed offset into the TLS data area.

The TLS array is an array of addresses that the system maintains for each thread. Each address in this array gives the location of TLS data for a given module (EXE or DLL) within the program. The TLS index indicates which member of the array to use. The index is a number (meaningful only to the system) that identifies the module.

https://docs.microsoft.com/en-us/windows/win32/debug/pe-format#the-tls-section

view this post on Zulip Wasmtime GitHub notifications bot (May 06 2021 at 10:26):

bjorn3 commented on Issue #1885:

The _tls_used handling should be done in object's coff write code, not in Cranelift.

Last updated: Dec 23 2024 at 12:05 UTC