SGX target: Expose thread id function in os module

[jethrogb]

In order to call std::os::fortanix_sgx::usercalls::send, you need the thread id. This exposes it through another function in std::os::fortanix_sgx.

I looked at how other platforms do this. On Windows and cfg(unix) you can get the OS handle from a thread::JoinHandle, but that's not sufficient, I need it for a thread::Thread. In the future, this functionality could be added to thread::Thread and this platform can follow suit.

r? @joshtriplett

[faern]

Would it make sense to add get_tcs_addr to fortanix-sgx-abi instead? Then it will be available to those who need the syscall, and std can just call where it's defined, it depends on that crate anyway.

I don't know the exact relationship between the fortanix-sgx-abi crate and libc and/or std. And I also don't know anything about SGX in particular, but I find it slightly odd that fortanix-sgx-abi defines the type Tcs and a method that takes it as an argument. But no way to actually obtain an instance.

[jethrogb]

No, get_tcs_addr is defined in std, so that's the only place it could reasonably be exposed. Also, the fortanix-sgx-abi crate is not meant to be used by users of std. All its types are re-exported in std::os::fortanix_sgx.

[jethrogb]

I find it slightly odd that fortanix-sgx-abi defines the type Tcs and a method that takes it as an argument. But no way to actually obtain an instance.

The fortanix-sgx-abi crate is a specification crate, it doesn't contain any actual implementations. Other crates (such as std) must provide implementations, so it provides the types (and macros) to help you do so.

[faern]

Ah. I see now that it's defined in entry.S. My bad! I thought it was just an extern declaration and provided by the system. In which case it would have fit in libc or similar.

[joshtriplett]

This looks reasonable to me.

@bors r+

[bors]

📌 Commit 67eabc6 has been approved by joshtriplett