Port libpanic_abort and libpanic_unwind to CloudABI

[EdSchouten]

This change ports both the libpanic* libraries to CloudABI.

The most interesting part of this pull request, however, is that it imports the CloudABI system call API into the Rust tree through a Git submodule. These will also be used by my port of libstd to CloudABI extensively, as that library obviously needs to invoke system calls to implement its primitives.

I have taken the same approach as libc: src/libcloudabi + src/rustc/cloudabi_shim. If some other naming scheme is preferred, feel free to let me know! As libcloudabi is pretty small, maybe it makes sense to copy, instead of using a submodule?

[rust-highfive]

r? @alexcrichton

(rust_highfive has picked a reviewer for you, use r? to override)

[kennytm]

Could we make libcloudabi a crates.io package instead of a submodule? (assuming we don't want to copy the files)

[alexcrichton]

Thanks! It looks like the bindings used here are pretty slim, would it be possible to inline the cloudabi crate definitions instead of pulling in a new submodule?

[EdSchouten]

Hi Kenny, Alex,

I have to confess I'm still a pretty much a newbie when it comes to Cargo, so I appreciate your input on this matter a lot.

We already have the CloudABI definitions as a crate on crates.io, called cloudabi. I personally think that it makes a lot of sense to depend on that instead of using a submodule, but I haven't managed to get that working properly. If I change the Cargo.toml files as follows:

--- a/src/libpanic_abort/Cargo.toml
+++ b/src/libpanic_abort/Cargo.toml
@@ -14,4 +14,4 @@ core = { path = "../libcore" }
 libc = { path = "../rustc/libc_shim" } 
 
 [target.'cfg(target_os = "cloudabi")'.dependencies]
-cloudabi = { path = "../rustc/cloudabi_shim" }
+cloudabi = { version = "0.0.2", default-features = false }
diff --git a/src/libstd/Cargo.toml b/src/libstd/Cargo.toml
index 5e4f5204aa..0b4433d879 100644
--- a/src/libstd/Cargo.toml
+++ b/src/libstd/Cargo.toml
@@ -39,7 +39,7 @@ rustc_msan = { path = "../librustc_msan" }
 rustc_tsan = { path = "../librustc_tsan" }
 
 [target.'cfg(target_os = "cloudabi")'.dependencies]
-cloudabi = { path = "../rustc/cloudabi_shim" }
+cloudabi = { version = "0.0.2", default-features = false }
 
 [build-dependencies]
 build_helper = { path = "../build_helper" }

I can no longer build a simple tool that makes use of the standard libraries:

$ xargo run --target x86_64-unknown-cloudabi
    Updating registry `https://github.com/rust-lang/crates.io-index`
   Compiling libc v0.2.35
   Compiling cloudabi v0.0.2
   Compiling cc v1.0.3
   Compiling unwind v0.0.0 (file:///home/ed/projects/rust/src/libunwind)
   Compiling cfg-if v0.1.2
   Compiling core v0.0.0 (file:///home/ed/projects/rust/src/libcore)
error[E0463]: can't find crate for `core`

This is probably because cloudabi depends on the wrong instance of core, right? In cloudabi_shim we explicitly override that to use libcore in the Rust source tree.

If depending on an external crate is going to be hard, I think that Alex's idea of inlining the crate definitions makes sense. Alex: I can copy over the .rs source files from the CloudABI source tree into src/libcloudabi and give that a custom Cargo.toml. Is that what you're proposing?

[alexcrichton]

Yes unfortunately anything that std depends on can't come vanilla from crates.io. The standard library depends explicitly (via Cargo.toml) on libcore, but nothing on crates.io does that so Cargo doesn't understand to sequence the compilations correctly. The shim crate is necessary to introduce this explicit dependency.

That being said though it'd be great if we could inline some specific pieces (perhaps unsafe). We already have way too many submodules as it is :(

[EdSchouten]

Thanks for confirming.

Right now there are two crates in my patched Rust source tree that make use of CloudABI's definitions: libpanic_abort and libstd. This is why I put this code in a shared cloudabi crate. That said, I may be able to avoid the dependency in libpanic_abort by using any of the two other code paths. Once removed, libstd remains the only consumer, meaning I can move the generated sources into src/libstd/sys/cloudabi/....

If it turns out there are other places in the source tree where a dependency on the generated sources is needed, we can reconsider creating a separate crate, but for now there are ways around it.

I'll update this pull request later today!

[EdSchouten]

Done! I think this pull request should now be good to go!

[alexcrichton]

@bors: r+

[bors]

📌 Commit 91611fc has been approved by alexcrichton