Android: make std thread APIs work

[RalfJung]

Basic thread spawning works on Android, but some things are still missing:

• setting/getting the thread name. This needs prctl commands PR_SET_NAME and PR_GET_NAME.
• the std synchronization primitives, which are built on futexes. Since Android uses the Linux kernel, futex support can be shared with Linux; this just requires a bit of refactoring to avoid copy-pasting all this.

(Also, we're looking for a target maintainer for Android, so please let us know if you're up to that -- basically someone we'd ping when there are Android questions, and in case std starts using a new Android API we'd hope they would be able to provide a Miri implementation.)

[YohDeadfall]

@rustbot claim

[YohDeadfall]

How should the code be refactored to share the sync module between linux and android? The last one is based on Linux, but has different user space which is compatible in some points. So, at least for me it means that for these places the shared part should be under linux module. Even some parts made for android can be interpreted for linux also like prctl.

How do you see the refactoring?

[RalfJung]

The easiest thing to do for futexes seems to be to move the Linux syscall shim into a separate function (still in the linux folder), and call that from Android.

Even some parts made for android can be interpreted for linux also like prctl.

That could do the same, have a function in the linux folder that is called from linux/foreign_items.rs and android/foreign_items.rs. The most tricky part here is how to test this without too much code duplication...

[YohDeadfall]

Got you, thanks!

There's one thing which is unclear to me. How do you decide what Miri should cover and in which cases? Since the issue is about prctl let's take it as an example. That system call is also available for linux, but its libc has prctl in it, but according to the implementation it won't be supported. That makes it's impossible to use prctl with Miri if someone decided to use it directly for whatever reason.

[RalfJung]

Generally we want to support what std needs. On top of that if things are widely used out there we'll consider adding support for them (if the API can be implemented and maintained with reasonable effort).

For prctl, given that we anyway have to carry an implementation for Android, we might as well expose it on Linux, too.