Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Target runner support #30

Open
roblabla opened this issue Jun 13, 2019 · 3 comments
Open

Target runner support #30

roblabla opened this issue Jun 13, 2019 · 3 comments
Labels
enhancement Improve the expected

Comments

@roblabla
Copy link

roblabla commented Jun 13, 2019

Cargo has a cute little-known feature that allows running binaries for other targets directly from the cargo commands. This works by having a runner configured for a given target triplet in the cargo configuration. From the cargo reference:

If a runner is provided, compiled targets for the $triple will be executed by invoking the specified runner executable with actual target as first argument. This applies to cargo run, cargo test and cargo bench commands. By default compiled targets are executed directly.

The usual use-case would be running the tests through qemu to make sure it works on different architecture (Running it under qemu-aarch64 to make sure it works on aarch64, etc...).

When escargot spawns a process as part of a CargoTest, it should ideally recover the runner and use it to run the test. This would require reading the .cargo/configs to get the appropriate runner, and running the test as ./runner ./test --testargs (instead of ./test --testargs)

@epage epage added the enhancement Improve the expected label Jun 13, 2019
@epage
Copy link
Contributor

epage commented Jun 13, 2019

I'm assuming this applies to both CargoTest and CargoRun.

Reading [target.$triple] on our own shouldn't be too bad. I'd b concerned about having to re-implement support for [target.'cfg(...)'] and we might need to look into another way of handling that part.

@epage
Copy link
Contributor

epage commented Jun 13, 2019

parse_cfg could help though it doesn't offer the actual matching logic.

Could probably steal the matching logic from runtime_cfg. I'm thinking we shouldn't use the crate directly because it is focused on handling ASTs for macros.

@roblabla
Copy link
Author

roblabla commented Jun 13, 2019

In cargo:

The logic to get the runner can be found here. As we can see, the logic is to figure out if two cfgs "match" through the matches_key function.

The cfg we are interested in is bcx.target_info.cfg(). target_info is a member of BuildContext. target_info itself is created based on the target, and basically calls rustc to figure out all its members.

So I straced rustc to figure out how it happens behind the scenes and here is how it's called:

rustc - --crate-name ___ --print=file-names $RUSTFLAGS --target $TARGET --crate-type bin --crate-type rlib --crate-type dylib --crate-type cdylib --crate-type staticlib --crate-type proc-macro --print=sysroot --print=cfg < /dev/null

(The --target is optional.)

This outputs something of the form:

___
lib___.rlib
lib___.so
lib___.so
lib___.a
lib___.so
/home/roblabla/.rustup/toolchains/stable-x86_64-unknown-linux-gnu
debug_assertions
proc_macro
target_arch="x86_64"
target_endian="little"
target_env="gnu"
target_family="unix"
target_feature="fxsr"
target_feature="sse"
target_feature="sse2"
target_os="linux"
target_pointer_width="64"
target_vendor="unknown"
unix

First line is crate name, 5 lines below are the names of the various crate types, the line below is the sysroot, and everything afterwards is a cfg. Every such cfg line is parsed with Cfg::from_str, and assembled into our final Vec that we'll use for our final comparison.

So I think this behavior should be fairly easy to replicate without too much trouble. None of this seems to use unstable flags, so it should all be stable to use? Might be a good idea to ask the cargo/rustc maintainers first though.

EDIT: 🤔 something interesting: cfg(feature = "") don't seem to be usable there. Cargo doesn't pass the --cfg features to rustc when asking it for the supported cfgs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Improve the expected
Projects
None yet
Development

No branches or pull requests

2 participants