Background: I’m using Rust for a cross-platform mobile library that is used within an Objective-C iOS application and a Java Android application (using a JNI shim also in Rust). I’ve a self-built Rust toolchain that targets seven mobile triples. The Rust code is complex enough to warrant the use of multiple crates and Cargo. So far, this approach is working well
The Rust code doesn’t create the threads of execution in my app, and as a result, the stack check prologues are occasionally misfiring on Android (they’re disabled by default for iOS targets). To fix this, I’ve built a new Rust toolchain with
morestack set to false within
src/librustc_back/target/android_base.rs. The reason for rolling this into the rust compiler rather than relying on the
no-stack-check rust compiler flag is the difficultly in passing this option to every Cargo dependency. Plus, I really need a no-stack-check
I’m aware that I’m losing out on safety by disabling the stack checks on Android, but since iOS doesn’t have them anyway, I figure I’m not really losing that much. Additionally, it isn’t obvious how I’d solve the problem of an external thread invoking my Rust function. Even if the entry points of my library were marked with
#[no_stack_check], I’d be severely limited in what
libstd functions I could use. Even if I was careful to only use functions also marked as
#[no_stack_check], the compiler wouldn’t help enforce this in the face of
libstd or my own code changing.
So, to my questions, most of which assume that Rust wishes to easily support the use-case of hosting a no-stack-check Rust library within another environment:
morestackhack described above, where I modify the compiler for Android targets, seem like a sensible approach to solving the issue?
Does any user documentation exist that explains the potentially problematic stack check prologues in the case of external threads invoking Rust functions?
Is there value in Cargo offering a way of passing Rust compiler flags to all dependencies of a crate (in this case, passing
Is there value in a Rust
configureoption that disables stack checks for a given target triple (akin to my
morestackhack described above)?
It seems that stack-check / no-stack-check is an axis perpendicular to that of the target triple axis, forming a variant of a triple. Anyone have any thoughts on this?
Given that the stack check prologues are not universally supported across all targets, what does the future hold for stack checking?
Is there, or is there value in adding, a compilation/linker lint for ensuring that a chain of function calls are all marked as
For (2), I blew a bunch of time debugging the crazy non-existent stack overflows, so I’m prepared to write a paragraph or two about this topic somewhere appropriate to save others the same pain.