add basic support for android targets #2011

landaire · 2022-03-09T19:46:50Z

This PR fixes #2010 by adding platform support for Android. This does a couple of things:

Supports weak linking for signal and bsd_signal syscalls. This is handled similarly to dlsym (dynamically linked) items where we call into the Dlsym::from_str for each weakly linked symbol, allocate a function for them, and write the pointer to the function at the slot for the weakly linked item.
Adds android as a supported platform for shims::posix::foreign_item emulation
Piggybacks off of the shims::posix::linux::foreign_items for foreign item emulation

This is marked as a draft until I figure out why my test (aka prod) application is hanging on one of its tests. I'm not sure if it's just really expensive and runs slow, or if one of the emulated syscalls works differently on Android.

Currently though this is enough support to run basic unit tests.

TODO:

Add tests? This may be a bigger change since we'd need to bring in the Android NDK for compiling stdlib
Add docs regarding platform support?
remove hard dependency on Android NDK presence when performing check builds rust#94813

src/shims/env.rs

RalfJung · 2022-03-09T20:02:15Z

Supports weak linking for signal and bsd_signal syscalls.

Shouldn't it be enough to implement one of them?

I'm not sure if it's just really expensive and runs slow, or if one of the emulated syscalls works differently on Android.

Which target triple do you even use for Android? Do some simple demos work? If there is concurrency involved you might be seeing #1388. You can use Miri's measureme support to figure out where the time is spent.

It would be good to add at least a smoke test to ci.sh, e.g.

MIRI_TEST_TARGET=something-android-something ./miri test hello

except it should probably go through run_tests to print the usual "Testing foreign architecture ..." blurb.

RalfJung · 2022-03-09T20:04:29Z

Oh, I just saw this:

we'd need to bring in the Android NDK for compiling stdlib

Are you sure? Miri uses check-only builds of the stdlib. I can build the macOS and even Windows stdlib for Miri on my Linux without installing anything for those targets. The same should work for Android I think (and if not we should fix that).

src/shims/env.rs

src/machine.rs

src/shims/dlsym.rs

src/shims/foreign_items.rs

landaire · 2022-03-09T20:14:35Z

Oh, I just saw this:

we'd need to bring in the Android NDK for compiling stdlib

Are you sure? Miri uses check-only builds of the stdlib. I can build the macOS and even Windows stdlib for Miri on my Linux without installing anything for those targets. The same should work for Android I think (and if not we should fix that).

I'm not 100% sure on this. I'm not an Android expert, I just happen to be working on a project that targets Android at the moment. While trying to run Miri initially I get an stdlib build failure here: https://github.com/rust-lang/rust/blob/10dccdc7fcbdc64ee9efe2c1ed975ab8c1d61287/library/unwind/build.rs#L13

cc uses this logic to detect a compiler when targeting Android, so either you'd need to lie about the Android compiler's presence by symlinking your regular target, or just install the NDK.

Which target triple do you even use for Android?

I use aarch64-linux-android.

Do some simple demos work?

A "Hello, world!" application works fine 🤷‍♂️

RalfJung · 2022-03-09T20:22:23Z

I'm not 100% sure on this. I'm not an Android expert, I just happen to be working on a project that targets Android at the moment. While trying to run Miri initially I get an stdlib build failure here: https://github.com/rust-lang/rust/blob/10dccdc7fcbdc64ee9efe2c1ed975ab8c1d61287/library/unwind/build.rs#L13

Ah, and it'll do that even for a check-only build.
We could adjust that build script to avoid calling cc when env::var_os("CARGO_CFG_MIRI").is_some() is true.

src/helpers.rs

landaire · 2022-03-09T21:59:16Z

It would be good to add at least a smoke test to ci.sh, e.g.
MIRI_TEST_TARGET=something-android-something ./miri test hello
except it should probably go through run_tests to print the usual "Testing foreign architecture ..." blurb.

~~Is there a way of running just the run run-pass test and not the UI test? Unfortunately it looks like the test runner requires an Android device to be present:~~

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 7 filtered out; finished in 0.00s

     Running tests/compiletest.rs (target/x86_64-apple-darwin/release/deps/compiletest-501d0a11df7d7b5b)
## Running run-pass tests in tests/run-pass against miri for target aarch64-linux-android
   Compiler flags: --edition 2018 -Dwarnings -Dunused --sysroot /Users/landerb/Library/Caches/org.rust-lang.miri

running 1 test
test [ui] run-pass/hello.rs ... thread 'main' panicked at 'android device not available', /Users/landerb/.cargo/registry/src/git.luolix.top-1ecc6299db9ec823/compiletest_rs-0.7.1/src/runtest.rs:57:17
stack backtrace:
   0: std::panicking::begin_panic
             at /rustc/89adcc636f94d34a6fc90fa117e28ddf6be7b983/library/std/src/panicking.rs:616:12
   1: compiletest_rs::runtest::run
             at /Users/landerb/.cargo/registry/src/git.luolix.top-1ecc6299db9ec823/compiletest_rs-0.7.1/src/runtest.rs:57:17
   2: compiletest_rs::make_test_closure::{{closure}}
             at /Users/landerb/.cargo/registry/src/git.luolix.top-1ecc6299db9ec823/compiletest_rs-0.7.1/src/lib.rs:300:9
   3: core::ops::function::FnOnce::call_once{{vtable.shim}}
             at /rustc/89adcc636f94d34a6fc90fa117e28ddf6be7b983/library/core/src/ops/function.rs:227:5
   4: <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once
             at /rustc/89adcc636f94d34a6fc90fa117e28ddf6be7b983/library/alloc/src/boxed.rs:1854:9
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
FAILED

failures:

failures:
    [ui] run-pass/hello.rs

I think I misunderstood what was going on here since 0 tests were run. Still not sure how to avoid the UI test failure though.

RalfJung · 2022-03-09T22:03:09Z

That is very odd... so ./miri run tests/run-pass/hello.rs --target aarch64-linux-android works?

landaire · 2022-03-09T22:06:21Z

That is very odd... so ./miri run tests/run-pass/hello.rs --target aarch64-linux-android works?

Correct. I think the test runner performs this check for just the UI tests because it expects to get stdout/stderr from a process running on the Android device over ADB. The code assumes that is if it's Android, it'll always talk over ADB.

RalfJung · 2022-03-09T22:07:01Z

Ah, compiletest special-cases android targets... that is annoying. :/

What happens when you just set config.adb_device_status = true around

miri/tests/compiletest.rs

Line 45 in 2da6bed

config.target_rustcflags = Some(flags);

?^^

src/machine.rs

landaire · 2022-03-09T22:37:40Z

What happens when you just set config.adb_device_status = true around

Perfect, that fixes the issue. What's better yet, after fixing a couple lingering issues it seems most tests pass:

failures:
    [ui] run-pass/concurrency/linux-futex.rs
    [ui] run-pass/concurrency/simple.rs
    [ui] run-pass/concurrency/sync.rs
    [ui] run-pass/current_dir.rs
    [ui] run-pass/current_dir_with_isolation.rs
    [ui] run-pass/fs.rs
    [ui] run-pass/fs_with_isolation.rs
    [ui] run-pass/hashmap.rs
    [ui] run-pass/heap_allocator.rs
    [ui] run-pass/libc.rs
    [ui] run-pass/linux-getrandom-without-isolation.rs
    [ui] run-pass/linux-getrandom.rs
    [ui] run-pass/panic/unsupported_syscall.rs

test result: FAILED. 213 passed; 13 failed; 1 ignored; 0 measured; 0 filtered out; finished in 39.58s

The failures here for the most part seem to be related to libc path lookup issues either at compile-time or runtime for some syscalls.

RalfJung · 2022-03-09T22:44:41Z

Nice. :) Seems fine to make them // ignore-android or so for now.

landaire · 2022-03-10T03:12:09Z

Ok, I'm stopping there for the night. I've gone down the rabbit hole of adding new foreign items as they pop up while running tests. Seems like the min supported Android API for Rust is missing a lot of modern Linux APIs that are otherwise used.

@RalfJung if this is becoming too much for an initial PR lmk and I'll undo the last change, get tests passing (aka ignore the ones lacking support), and create another PR with the new foreign items supported.

well I guess by asking that question I'm admitting it's grown in scope. I'm going to go ahead and pull the later changes into a smaller PR.

landaire · 2022-03-10T04:07:28Z

RIP, we hit the unwind build script panic. I'll make a PR for that soon.

landaire · 2022-03-10T19:00:24Z

You can use Miri's measureme support to figure out where the time is spent.

@RalfJung do you know enough about measureme's internals to say whether or not the output file is corrupt if you end the process with CTRL+C? Seems like the profiling data I need becomes corrupt for this testcase and causes analyzeme to panic :(

RalfJung · 2022-03-10T19:39:56Z

Sorry, no I don't. Maybe you could open an issue, then I can Cc the author of that support?

RalfJung · 2022-03-10T19:44:15Z

well I guess by asking that question I'm admitting it's grown in scope. I'm going to go ahead and pull the later changes into a smaller PR.

Yeah, splitting things up into smaller chunks helps a lot with reviewing. Thanks. :)

Now that you got more and more things to run, what is your thinking on treating Android as a separate Posix/Unix variant vs merging it with Linux? (Other ways to share code might be to factor things into common helper functions -- like how all the FS logic is shared between Linux and macOS.)

landaire · 2022-06-04T17:51:14Z

All tests now pass, but you must still make the necessary change to the stdlib's unwind/build.rs so it does not invoke cc. I've commented out the Android tests from the ci.sh file with a note to restore it when rust-lang/rust#94813 lands.

RalfJung · 2022-06-04T20:27:46Z

README.md

@@ -214,6 +214,9 @@ degree documented below):
  supported on Windows. We also test `i686-pc-windows-msvc`, with the same
  reduced feature set. We might ship Miri with a nightly even when some features
  on these targets regress.
+- `aarch64-linux-android` has basic support and should work for simple targets.


What are "simple targets"?

Also it seems a bit premature to add this if we don't have anything on CI and people need to patch stdlib to make it work.

RalfJung · 2022-06-04T20:30:38Z

src/helpers.rs

+
+/// Helper function used inside the shims of foreign functions to check that the `target_os` is
+/// part of the UNIX family.
+pub fn target_os_is_unix(target_os: &str) -> bool {


Elsewhere we are using target.families.iter().any(|f| f == "unix"). I think that probably makes more sense?

So, please change this to take a &Target and also adjust the existing checks to call this function instead.

Actually, thinking about it more -- I like explicitly listing the unix OSes that we do support. So let's go with your approach.

But please change the existing code that checks target.families to call target_os_is_unix instead.

Could you or @InfRandomness make a separate PR that does nothing but add target_os_is_unix and use it where appropriate? Then both the FreeBSD PR and this one can just adjust that function and don't need to change so many different places in the code.

RalfJung · 2022-06-04T20:31:19Z

src/machine.rs

+                    this.write_scalar(Scalar::from_machine_usize(0, this), &place.into())?;
+                    Self::add_extern_static(this, name, place.ptr);
+                }
+                for symbol_name in &["signal", "bsd_signal"] {


Suggested change

for symbol_name in &["signal", "bsd_signal"] {

// Some weak symbols that we *do* (have to) support.

for symbol_name in &["signal", "bsd_signal"] {

RalfJung · 2022-06-04T20:32:10Z

src/machine.rs

+                    this.write_scalar(Scalar::from_machine_usize(0, this), &place.into())?;
+                    Self::add_extern_static(this, name, place.ptr);
+                }
+                for symbol_name in &["signal", "bsd_signal"] {


Shouldn't it be enough to implement one of them?

Unfortunately not. If you try to run without both you get the following panic:

error: unsupported operation: `extern` static `std::sys::unix::android::signal::bsd_signal` from crate `std` is not supported by Miri --> /Users/hvx/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/src/rust/library/std/src/sys/unix/android.rs:76:5 | 76 | weak!(fn bsd_signal(c_int, sighandler_t) -> sighandler_t); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `extern` static `std::sys::unix::android::signal::bsd_signal` from crate `std` is not supported by Miri | = help: this is likely not a bug in the program; it indicates that the program performed an operation that the interpreter does not support = note: inside `std::sys::unix::android::signal` at /Users/hvx/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/src/rust/library/std/src/sys/unix/weak.rs:41:38 = note: inside `std::sys::unix::init::reset_sigpipe` at /Users/hvx/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/src/rust/library/std/src/sys/unix/mod.rs:122:19 = note: inside `std::sys::unix::init` at /Users/hvx/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/src/rust/library/std/src/sys/unix/mod.rs:64:5 = note: inside `std::rt::init` at /Users/hvx/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/src/rust/library/std/src/rt.rs:78:9 = note: inside closure at /Users/hvx/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/src/rust/library/std/src/rt.rs:127:42 = note: inside `std::panicking::try::do_call::<[closure@std::rt::lang_start_internal::{closure#1}], ()>` at /Users/hvx/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/src/rust/library/std/src/panicking.rs:492:40 = note: inside `std::panicking::try::<(), [closure@std::rt::lang_start_internal::{closure#1}]>` at /Users/hvx/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/src/rust/library/std/src/panicking.rs:456:19 = note: inside `std::panic::catch_unwind::<[closure@std::rt::lang_start_internal::{closure#1}], ()>` at /Users/hvx/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/src/rust/library/std/src/panic.rs:137:14 = note: inside `std::rt::lang_start_internal` at /Users/hvx/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/src/rust/library/std/src/rt.rs:127:5 = note: inside `std::rt::lang_start::<()>` at /Users/hvx/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/src/rust/library/std/src/rt.rs:144:17 = note: this error originates in the macro `weak` (in Nightly builds, run with -Z macro-backtrace for more info)

This is caused by the standard library weak linking both symbols https://github.com/rust-lang/rust/blob/1eb72580d076935a3e590deb6e5813a5aef3eca4/library/std/src/sys/unix/android.rs#L74-L81

But you can make one of them NULL. Only one needs to be implemented.

Ah I see what you mean. Can do.

RalfJung · 2022-06-04T20:33:00Z

src/machine.rs

+                    let ecx = this.eval_context_mut();
+                    let ptr = ecx.create_fn_alloc_ptr(FnVal::Other(dlsym));


Suggested change

let ecx = this.eval_context_mut();

let ptr = ecx.create_fn_alloc_ptr(FnVal::Other(dlsym));

let ptr = this.create_fn_alloc_ptr(FnVal::Other(dlsym));

RalfJung · 2022-06-04T20:35:00Z

src/machine.rs

+                    let ptr = ecx.create_fn_alloc_ptr(FnVal::Other(dlsym));
+
+                    let place = this.allocate(layout, MiriMemoryKind::ExternStatic.into())?;
+                    this.write_pointer(ptr, &place.into())?;


Can you add a helper function that takes the symbol name and returns a Place containing a pointer pointing to that function?
I'd like to keep init_extern_statics as short and readable as possible.

RalfJung · 2022-06-04T20:36:34Z

src/helpers.rs

@@ -883,3 +905,9 @@ impl std::fmt::Display for HexRange {
        write!(f, "[{:#x}..{:#x}]", self.0.start.bytes(), self.0.end().bytes())
    }
 }
+
+/// Helper function used inside the shims of foreign functions to check that the `target_os` is
+/// part of the UNIX family.


Suggested change

/// part of the UNIX family.

/// a supported OS in the UNIX family.

RalfJung · 2022-06-04T20:39:45Z

src/shims/posix/foreign_items.rs

+                    throw_ub_format!("memalign: alignment must be a power of two, but is {}", align);
+                }
+
+                let ptr = this.allocate_ptr(


Like malloc, this probably should return NULL if the size is 0.

RalfJung · 2022-06-04T20:41:18Z

src/shims/posix/linux/foreign_items.rs

@@ -134,7 +135,12 @@ pub trait EvalContextExt<'mir, 'tcx: 'mir>: crate::MiriEvalContextExt<'mir, 'tcx

                let sys_getrandom = this.eval_libc("SYS_getrandom")?.to_machine_usize(this)?;

-                let sys_statx = this.eval_libc("SYS_statx")?.to_machine_usize(this)?;
+                let sys_statx = if target_os == "android" {
+                    // libc's Android target currently does not support SYS_statx -- fail gracefully


Isn't this doing a syscall basically directly to the kernel?

If we need such an if, this is a strong indication that we should not share this code between android and linux, IMO.

That's correct. This special case is required as the libc crate does not support a lot of constants and structures for Android even though they do exist, someone just has to make a PR. If you agree we should copy the Linux handlers to the Android foreign_items to separate them then I can just remove this condition.

RalfJung · 2022-06-04T20:42:53Z

src/shims/posix/android/foreign_items.rs

+            _ => {
+                // By default we piggyback off the items emulated for Linux. For now this functions
+                // serves to make adding android-specific syscalls easy
+                return shims::posix::linux::foreign_items::EvalContextExt::emulate_foreign_item_by_name(this, link_name, abi, args, dest, ret);


I am not very happy about this fallback. The linux functions are not prepared for android use, and we didn't check that their implementation is correct against their android specification. Android has its completely separate libc, and the API we are implementing here is basically that of libc.

So, I am not convinced that we want to fall back like this here; to me this seems to carry a huge risk of accidentally using the wrong shim implementation.

That makes sense. I originally went with this approach since Android is Linux-based, but you're right that if we're implementing the libc API, we should probably ensure these are separate.

What would you suggest, just copying the Linux code here?

I would suggest copying enough of the Linux code to get hello.rs working on Android -- and leaving everything else to a future PR.

RalfJung · 2022-06-04T20:44:05Z

tests/pass/concurrency/simple.rs

@@ -1,4 +1,5 @@
 // ignore-windows: Concurrency on Windows is not supported yet.
+// ignore-android: `libc` crate does not support `PR_SET_NAME` on Android


This code does not directly call libc though. It just uses standard library APIs. So it should work on Android as well, right?

Sorry, these comments in the tests were notes about the root cause of why the feature is not supported, and therefore why the test is ignored. I can reword this and the other locations to be more concise.

FWIW this is the (trimmed) panic you receive running this test:

thread '<unnamed>' panicked at 'Hello!', tests/pass/concurrency/simple.rs:55:9 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace thread 'rustc' panicked at 'failed to find required Rust item: ["libc", "PR_SET_NAME"]', src/helpers.rs:82:32 stack backtrace: 0: 0x1027845f4 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h34a40067a35bfbec 1: 0x1027def6b - core::fmt::write::h90d56a63b82c1d78 2: 0x102776c18 - std::io::Write::write_fmt::h9a11e832e4a1e526 3: 0x10278797d - std::panicking::default_hook::{{closure}}::h50f5199bcbe28750 4: 0x1027876f7 - std::panicking::default_hook::h95b189cf93ee7eab 5: 0x10fe9a05d - rustc_driver[8cbe49adf889e25c]::DEFAULT_HOOK::{closure#0}::{closure#0} 6: 0x102787fdb - std::panicking::rust_panic_with_hook::hde5cf82e5f0b952b 7: 0x102787e53 - std::panicking::begin_panic_handler::{{closure}}::h02042140a786e7a4 8: 0x102784a77 - std::sys_common::backtrace::__rust_end_short_backtrace::ha59ad93f482bafe0 9: 0x102787b2a - _rust_begin_unwind 10: 0x102808703 - core::panicking::panic_fmt::hd46cbc4cb5821886 11: 0x101e2404f - miri::helpers::EvalContextExt::resolve_path::{{closure}}::h0ec9ed0c1bb395ff at /Users/hvx/dev/miri/src/helpers.rs:82:32 12: 0x101e2404f - core::option::Option<T>::unwrap_or_else::h0d7d7e05cfeea290 at /rustc/e71440575c930dcecac288b7c3536410d688b351/library/core/src/option.rs:825:21 13: 0x101e2404f - miri::helpers::EvalContextExt::resolve_path::h00886eb1a3d5bd0f at /Users/hvx/dev/miri/src/helpers.rs:81:9 14: 0x101e2404f - miri::helpers::EvalContextExt::eval_path_scalar::h8283fff130397323 at /Users/hvx/dev/miri/src/helpers.rs:89:24 15: 0x101e65095 - miri::helpers::EvalContextExt::eval_libc::h5c2d4c27033a0621 at /Users/hvx/dev/miri/src/helpers.rs:98:9 16: 0x101e65095 - miri::helpers::EvalContextExt::eval_libc_i32::h506af73185e8afd7 at /Users/hvx/dev/miri/src/helpers.rs:104:9 17: 0x101e65095 - miri::shims::posix::thread::EvalContextExt::prctl::he65e14925b5442ba at /Users/hvx/dev/miri/src/shims/posix/thread.rs:110:22 18: 0x101e65fb4 - miri::shims::posix::linux::foreign_items::EvalContextExt::emulate_foreign_item_by_name::h2a3aca9b29812087 at /Users/hvx/dev/miri/src/shims/posix/linux/foreign_items.rs:110:30 19: 0x101e65796 - miri::shims::posix::android::foreign_items::EvalContextExt::emulate_foreign_item_by_name::h2477024ea6b084a5 at /Users/hvx/dev/miri/src/shims/posix/android/foreign_items.rs:24:24 20: 0x101e4fc1c - miri::shims::posix::foreign_items::EvalContextExt::emulate_foreign_item_by_name::h972a07cae6d0156c at /Users/hvx/dev/miri/src/shims/posix/foreign_items.rs:499:41 21: 0x101e2fb1c - miri::shims::foreign_items::EvalContextExt::emulate_foreign_item_by_name::hc7eb92b0e9675c1b at /Users/hvx/dev/miri/src/shims/foreign_items.rs:705:63 22: 0x101df5e85 - miri::shims::foreign_items::EvalContextExt::emulate_foreign_item::hf8d1dc31e7e38b74 at /Users/hvx/dev/miri/src/shims/foreign_items.rs:302:15 23: 0x101df5e85 - miri::shims::EvalContextExt::find_mir_or_eval_fn::h67395dcac9bbe974 at /Users/hvx/dev/miri/src/shims/mod.rs:54:20

Right, that is caused by you calling our linux-specific implementation of prctl on a non-Linux target.

This confirms my stance that android should not just fall back to the Linux functions. That leads to the weirdest failures, in the best case -- or to silently wrong behavior in the worst case.

RalfJung · 2022-06-04T20:44:54Z

tests/pass/concurrency/sync.rs

@@ -1,4 +1,5 @@
 // ignore-windows: Concurrency on Windows is not supported yet.
+// ignore-android: `libc` crate does not support `gettimeofday()` on Android


Please reword this to document which stdlib API Miri does not support on Android. (I assume with rustc, this code here works fine on Android.)

RalfJung · 2022-06-04T20:45:20Z

tests/pass/current_dir.rs

@@ -1,3 +1,4 @@
+// ignore-android: No foreign function support for __errno yet


What does this have to do with what the test is doing?

Same as the test/pass/concurrency/simple.rs comment this is relating to the panic raised when actually running the test. I won't blow up your notifications on each instance here, but that's the general theme with the ignore-android comments.

RalfJung · 2022-06-04T20:45:50Z

tests/pass/hashmap.rs

@@ -1,3 +1,5 @@
+// ignore-android: libc for Android does not have `SYS_statx`


What does the hashmap have to do with statx?

RalfJung · 2022-06-04T20:46:25Z

tests/pass/libc.rs

@@ -1,4 +1,5 @@
 // ignore-windows: No libc on Windows
+// ignore-android: libc's Android target does not have support for __errno_location yet


And that affects all tests in this file?

RalfJung · 2022-06-04T20:47:48Z

src/shims/posix/android/dlsym.rs

+        let ret = ret.expect("we don't support any diverging dlsym");
+
+        match dlsym {
+            Dlsym::signal => {


The POSIX version of this is gated on this.frame_in_std(), probably we should do the same here? After all we don't actually do anything...

bors · 2022-06-06T13:12:43Z

☔ The latest upstream changes (presumably #2198) made this pull request unmergeable. Please resolve the merge conflicts.

RalfJung · 2022-06-10T19:47:13Z

ci.sh

@@ -50,6 +51,8 @@ case $HOST_TARGET in
    MIRI_TEST_TARGET=i686-unknown-linux-gnu run_tests
    MIRI_TEST_TARGET=aarch64-apple-darwin run_tests
    MIRI_TEST_TARGET=i686-pc-windows-msvc run_tests
+    # TODO: Enable once https://github.com/rust-lang/rust/pull/94813 lands
+    # MIRI_TEST_TARGET=aarch64-linux-android run_tests


Could you add a note that @landaire is maintaining this target -- so that we know whom to ping when something android-specific breaks?

RalfJung · 2022-07-13T00:07:20Z

Btw we have the concept of a "minimal" target now that only runs a subset of the tests. It's a great way to get started with a new target and then improve its support step-by-step.

So IMO the first PR should just add run_tests_minimal hello to ci.sh for the android target, and then we can grow from there.

RalfJung · 2022-07-22T12:37:40Z

I am going to close this PR due to inactivity; @landaire feel free to reopen if/when you get back to this. :)

RalfJung · 2022-08-18T12:35:16Z

FWIW #2493 resurrects a part of this PR to get at least very basic android support. I don't plan to spend any more time on this though.

add very basic Android support This is just enough to print to stdout. I won't push this any further, but having these basics should hopefully make it easier for others to do so. Also slightly improve threading support on FreeBSD while we are at it. Partially based on #2011. Fixes #2010.

landaire · 2022-08-18T14:16:35Z

@RalfJung I apologize for dragging my feet on this. It was on my TODO list to come back around but I've been too busy give it the necessary focus to make the changes necessary. Thanks for taking the lead.

landaire commented Mar 9, 2022

View reviewed changes

src/shims/env.rs Outdated Show resolved Hide resolved

landaire force-pushed the feature/android-support branch from 7828dcc to 8c0242d Compare March 9, 2022 19:49

RalfJung mentioned this pull request Mar 9, 2022

Rename Posix → Unix #2012

Closed

landaire force-pushed the feature/android-support branch from 8c0242d to a5820cd Compare March 9, 2022 20:07

landaire commented Mar 9, 2022

View reviewed changes

src/shims/env.rs Show resolved Hide resolved