Add shims for gettid-esque functions
#4397
Conversation
tgross35
force-pushed
the
gettid-shims
branch
4 times, most recently
from
4ca7e19 to
82b76b0
Compare
src/shims/env.rs
Outdated
| /// Get an "OS" thread ID for any thread. | ||
| fn get_tid(&self, thread: ThreadId) -> u32 { | ||
| let this = self.eval_context_ref(); | ||
| let index = thread.to_u32(); | ||
|
|
||
| // todo: is this also true on Windows? | ||
| // Compute a TID for this thread, ensuring that the main thread has PID == TID. | ||
| this.get_pid().strict_add(index) | ||
| } |
There was a problem hiding this comment.
@ChrisDenton is there any relationship between the PID and TIDs on Windows?
This (preexisting) logic works for Unix because the first TID for a process is the same as the PID, but if that logic isn't true on Windows then I'll need to update this. If it is true on Windows, then I think the CreateThread shim needs to get updated to return the same TID logic in lpThreadId (hence the failing test).
There was a problem hiding this comment.
On Windows thread IDs and process IDs are unrelated.
There was a problem hiding this comment.
But it doesn't hurt to use the Unix scheme on Windows as well I guess?
There was a problem hiding this comment.
Great, that makes things easier. Thanks.
There was a problem hiding this comment.
Oops, I replied before seeing your message Ralf. Apparently it seems like a Linux thing more specifically than a Unix thing, I can't find documentation for other platforms about a relationship between PID and TID.
I just updated to only offset by PID on Linux, but do you prefer I put it back on all platforms and update the ID saved by CreateThread instead?
There was a problem hiding this comment.
Just checked a handful of different platforms on cfarm:
Linux
main tid 2212321 0x21c1e1
main pid 2212321 0x21c1e1
FreeBSD:
main tid 0 0
main pid 23750 0x5cc6
OpenBSD:
main tid 137368 0x21898
main pid 93069 0x16b8d
NetBSD:
main tid 5057 0x13c1
main pid 5057 0x13c1
NetBSD checking a spawned thread
in spawn: pid 1474 0x5c2 tid 13912 0x3658
in main: pid 1474 0x5c2 tid 1474 0x5c2
MacOS:
main tid 7763176 0x7674e8
main pid 51507 0xc933
Based on that nonscientific experiment I'll add NetBSD to the list of platforms that says tid is an offset from pid. For the others it's probably actually better that they don't line up, so users don't rely on that non-cross-platform behavior.
tgross35
changed the title
gettid and similar functionsgettid-esque functions
tgross35
force-pushed
the
gettid-shims
branch
5 times, most recently
from
3add687 to
eda5348
Compare
tgross35
force-pushed
the
gettid-shims
branch
2 times, most recently
from
14a3826 to
72a99da
Compare
|
Updated to include the |
tgross35
force-pushed
the
gettid-shims
branch
3 times, most recently
from
7f29fbb to
2a46fbe
Compare
| @@ -53,6 +55,11 @@ pub fn syscall<'tcx>( | |||
| let result = ecx.eventfd(initval, flags)?; | |||
| ecx.write_int(result.to_i32()?, dest)?; | |||
| } | |||
| num if num == sys_gettid => { | |||
| let [] = check_exact_vararg_count("syscall(SYS_gettid, ...)", varargs)?; | |||
There was a problem hiding this comment.
The other syscalls here seem to allow more than the required number of arguments. Should this just do the same and disregard arguments?
On one hand, it can't be UB to call varidics with more arguments than they expect, unless the function you're calling is doing something sadistic with asm. On the other hand, if you are passing more arguments here, you're doing something outside of the documented API.
Various platforms provide a function to return the current OS thread ID, but they all use a slightly different name. Add shims for these functions for Apple, FreeBSD, and Windows, with tests to account for those and a few more platforms that are not yet supported by Miri. The syscall and extern symbol is included as well on Linux. These should be useful in general but should also help support printing the OS thread ID in panic messages [1]. [1]: rust-lang/rust#115746
Various platforms provide a function to return the current OS thread ID, but they all use a slightly different name. Add shims for these functions for Apple, FreeBSD, and Windows, with tests to account for a few more platforms that are not yet supported by Miri.
These should be useful in general but should also help support printing the OS thread ID in panic messages 1.