forward the bootstrap `runner` to `run-make` #141856

folkertdev · 2025-06-01T13:33:05Z

The runner was already forwarded to compiletest, this just passes it on to run-make and uses it in the run functions.

The configuration can look like this

# in bootstrap.toml
[target.s390x-unknown-linux-gnu]
runner = "qemu-s390x -L /usr/s390x-linux-gnu"

Any C compilation automatically sets the correct target. Calls to rustc must use .target(target()). Then, a command like below will work by cross-compiling to the given target, and using the given runner for that target to execute the binary:

./x test tests/run-make/c-link-to-rust-va-list-fn --target s390x-unknown-linux-gnu

The runner can also be used for e.g. running with valgrind.

This PR also enables its use in the test case that I care about, hopefully that actually does work on the platforms that CI uses. We should probably run some try jobs to be sure?

r? @jieyouxu

try-job: test-various
try-job: armhf-gnu

rustbot · 2025-06-01T13:33:11Z

Some changes occurred in src/tools/compiletest

cc @jieyouxu

This PR modifies run-make tests.

cc @jieyouxu

The run-make-support library was changed

cc @jieyouxu

jieyouxu

Thanks, one nit

src/tools/run-make-support/src/run.rs

tests/run-make/c-link-to-rust-va-list-fn/rmake.rs

jieyouxu · 2025-06-01T13:37:54Z

This PR also enables its use in the test case that I care about, hopefully that actually does work on the platforms that CI uses. We should probably run some try jobs to be sure?

Do you happen to know which CI jobs? armhf-gnu?

folkertdev · 2025-06-01T13:43:27Z

I really don't know what cross-compilation actually happens in our CI and would run this run-make test. I've locally run this test for powerpc and s390x. Testing it with a 32-bit arm sounds like a good idea at least.

jieyouxu · 2025-06-01T13:49:12Z

Let's give it a try.
@bors try

…r, r=<try> forward the bootstrap `runner` to `run-make` The runner was already forwarded to `compiletest`, this just passes it on to `run-make` and uses it in the `run` functions. The configuration can look like this ```toml # in bootstrap.toml [target.s390x-unknown-linux-gnu] runner = "qemu-s390x -L /usr/s390x-linux-gnu" ``` Any C compilation automatically sets the correct target. Calls to rustc must use `.target(target())`. Then, a command like below will work by cross-compiling to the given target, and using the given runner for that target to execute the binary: ``` ./x test tests/run-make/c-link-to-rust-va-list-fn --target s390x-unknown-linux-gnu ``` The runner can also be used for e.g. running with `valgrind`. This PR also enables its use in the test case that I care about, hopefully that actually does work on the platforms that CI uses. We should probably run some try jobs to be sure? r? `@jieyouxu` try-job: test-various try-job: armhf-gnu

bors · 2025-06-01T13:50:23Z

⌛ Trying commit ab6646a with merge 1d3fe3c...

jieyouxu · 2025-06-01T13:51:28Z

Reminder (for myself): if try job fails, use @bors2 try to try out new bors

rust-bors · 2025-06-01T13:51:31Z

Unknown command "try`".

bors · 2025-06-01T14:26:38Z

💔 Test failed - checks-actions

jieyouxu · 2025-06-01T14:35:16Z

You probably need sth like //@ ignore-unknown (needs target std)

folkertdev · 2025-06-01T14:56:16Z

Hmm, that directive is never actually used, and also does not solve the issue for that target. It is a known target, just not one that has std (just core I assume). None of the directives in the list seem to really capture this? Maybe needs-threads is a decent proxy but that's not ideal.

jieyouxu · 2025-06-01T15:16:05Z

Yeah, a proper fix is sth like //@ needs-std, but for this PR, //@ ignore-none is a proxy for ignoring the *-unknown targets. I suppose //@ ignore-nvptx is better tho.

EDIT: opened #141863

jieyouxu · 2025-06-01T15:16:28Z

Hmm, that directive is never actually used, and also does not solve the issue for that target. It is a known target, just not one that has std (just core I assume). None of the directives in the list seem to really capture this? Maybe needs-threads is a decent proxy but that's not ideal.

(Sorry, I wrote //@ ignore-unknown but I meant //@ ignore-none as a temporary directive to unblock this PR)

folkertdev · 2025-06-01T15:51:34Z

Apparently you need to explicitly exluce nvptx (several other tests do this).

//@ ignore-none
// Reason: no-std is not supported
//@ ignore-nvptx64-nvidia-cuda
// Reason: can't find crate for 'std'

jieyouxu · 2025-06-01T16:09:41Z

Right. Because the nvptx64 target doesn't have a none in target name...

folkertdev · 2025-06-02T11:27:05Z

@jieyouxu can you rerun the try jobs here?

jieyouxu · 2025-06-02T11:33:16Z

Sure.
@bors2 try

…r, r=<try> forward the bootstrap `runner` to `run-make` The runner was already forwarded to `compiletest`, this just passes it on to `run-make` and uses it in the `run` functions. The configuration can look like this ```toml # in bootstrap.toml [target.s390x-unknown-linux-gnu] runner = "qemu-s390x -L /usr/s390x-linux-gnu" ``` Any C compilation automatically sets the correct target. Calls to rustc must use `.target(target())`. Then, a command like below will work by cross-compiling to the given target, and using the given runner for that target to execute the binary: ``` ./x test tests/run-make/c-link-to-rust-va-list-fn --target s390x-unknown-linux-gnu ``` The runner can also be used for e.g. running with `valgrind`. This PR also enables its use in the test case that I care about, hopefully that actually does work on the platforms that CI uses. We should probably run some try jobs to be sure? r? `@jieyouxu` try-job: test-various try-job: armhf-gnu

jieyouxu · 2025-06-02T12:06:46Z

@bors2 try

rust-bors · 2025-06-02T12:06:50Z

⌛ Trying commit e3fee6a with merge 6deab9d…

…r, r=<try> forward the bootstrap `runner` to `run-make` The runner was already forwarded to `compiletest`, this just passes it on to `run-make` and uses it in the `run` functions. The configuration can look like this ```toml # in bootstrap.toml [target.s390x-unknown-linux-gnu] runner = "qemu-s390x -L /usr/s390x-linux-gnu" ``` Any C compilation automatically sets the correct target. Calls to rustc must use `.target(target())`. Then, a command like below will work by cross-compiling to the given target, and using the given runner for that target to execute the binary: ``` ./x test tests/run-make/c-link-to-rust-va-list-fn --target s390x-unknown-linux-gnu ``` The runner can also be used for e.g. running with `valgrind`. This PR also enables its use in the test case that I care about, hopefully that actually does work on the platforms that CI uses. We should probably run some try jobs to be sure? r? `@jieyouxu` try-job: test-various try-job: armhf-gnu

rust-bors · 2025-06-02T12:32:03Z

💔 Test failed

CI ❌

jieyouxu · 2025-06-02T12:33:43Z

Hmm

2025-06-02T12:31:25.8166441Z error: linking with `rust-lld` failed: exit status: 1
2025-06-02T12:31:25.8166509Z   |
2025-06-02T12:31:25.8168630Z   = note:  "rust-lld" "-flavor" "wasm" "--export" "foo" "-z" "stack-size=1048576" "--stack-first" "--allow-undefined" "--no-demangle" "<2 object files omitted>" "<sysroot>/lib/rustlib/wasm32-wasip1/lib/{libstd-*,libpanic_abort-*,libwasi-*,librustc_demangle-*,libstd_detect-*,libhashbrown-*,librustc_std_workspace_alloc-*,libminiz_oxide-*,libadler2-*,libunwind-*,libcfg_if-*,liblibc-*}.rlib" "-l" "c" "<sysroot>/lib/rustlib/wasm32-wasip1/lib/{liballoc-*,librustc_std_workspace_core-*,libcore-*,libcompiler_builtins-*}.rlib" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/run-make/wasm-symbols-not-exported/rmake_out" "-L" "<sysroot>/lib/rustlib/wasm32-wasip1/lib/self-contained" "-o" "foo.wasm" "--gc-sections" "--no-entry" "-O0"
2025-06-02T12:31:25.8168950Z   = note: some arguments are omitted. use `--verbose` to show all linker arguments
2025-06-02T12:31:25.8169068Z   = note: rust-lld: error: unable to find library -lc

The runner was already forwarded to `compiletest`, this just passes it on to `run-make` and uses it in the `run` functions.

folkertdev · 2025-06-02T16:22:27Z

That is weird, it does work for me locally:

> WASI_SDK_PATH="~/Downloads/wasi-sdk-24.0-x86_64-linux" ./x test tests/run-make/c-link-to-rust-va-list-fn --target wasm32-wasip1

...

Testing stage1 compiletest suite=run-make mode=run-make (x86_64-unknown-linux-gnu -> wasm32-wasip1)

running 1 tests

.

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 401 filtered out; finished in 348.41ms

Should we investigate that further, or just ignore wasm32 and wasm64 for now?

jieyouxu · 2025-06-02T16:32:00Z

Should we investigate that further, or just ignore wasm32 and wasm64 for now?

That's a lot of tests, I don't particularly want to regress them like this. I'll try to take a look tmrw.

@rustbot review

folkertdev · 2025-06-02T17:23:59Z

Oh right, the test that I adjusted actually passes, but a bunch of others don't for a variety of reasons. That is really strange, the only thing that change there (I think) is that maybe the runner is set based on bootstrap.toml or other arguments to compiletest.

So the lld thing is weird, but these are even weirder: from alloc-no-oom-handling:

stdout: none
--- stderr -------------------------------
command failed at line 14
Command { cmd: LD_LIBRARY_PATH="/checkout/obj/build/x86_64-unknown-linux-gnu/test/run-make/alloc-no-oom-handling/rmake_out:/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib:/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-bootstrap-tools/x86_64-unknown-linux-gnu/release/deps:/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/lib:/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/lib/rustlib/x86_64-unknown-linux-gnu/lib" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/run-make/alloc-no-oom-handling/rmake_out" "--edition" "2021" "-Dwarnings" "--crate-type" "rlib" "/checkout/library/alloc/src/lib.rs" "--cfg" "no_global_oom_handling", stdin_buf: None, stdin: None, stdout: None, stderr: None, drop_bomb: DropBomb { command: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc", defused: true, armed_location: Location { file: "/checkout/tests/run-make/alloc-no-oom-handling/rmake.rs", line: 8, col: 5 } }, already_executed: true }
output status: `exit status: 1`
=== STDOUT ===



=== STDERR ===
error[E0463]: can't find crate for `core`
  |
  = note: the `x86_64-unknown-linux-gnu` target may not be installed
  = help: consider downloading the target with `rustup target add x86_64-unknown-linux-gnu`
  = help: consider building the standard library from source with `cargo build -Zbuild-std`

error: aborting due to 1 previous error

For more information about this error, try `rustc --explain E0463`.

One difference I'm seeing is that locally I use stage1 but CI uses stage2. I don't see why that would matter though. In any case I'll push a rebase with the new stage0 machinery.

jieyouxu · 2025-06-04T10:09:28Z

(A bit caught up with other things, I'll take a look on Saturday.)

rustbot assigned jieyouxu Jun 1, 2025

jieyouxu approved these changes Jun 1, 2025

View reviewed changes

src/tools/run-make-support/src/run.rs Outdated Show resolved Hide resolved

tests/run-make/c-link-to-rust-va-list-fn/rmake.rs Show resolved Hide resolved

folkertdev force-pushed the run-make-forward-compiletest-runner branch from 3f206ce to ab6646a Compare June 1, 2025 13:39

jieyouxu mentioned this pull request Jun 1, 2025

New bors looks within markdown code blocks rust-lang/bors#295

Open

This comment has been minimized.

Sign in to view

bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 1, 2025

This comment has been minimized.

Sign in to view

jieyouxu mentioned this pull request Jun 1, 2025

Consider adding a //@ needs-std directive for target std support #141863

Open

folkertdev force-pushed the run-make-forward-compiletest-runner branch from ab6646a to e3fee6a Compare June 1, 2025 15:52

This comment has been minimized.

Sign in to view

folkertdev closed this Jun 1, 2025

folkertdev reopened this Jun 1, 2025

This comment was marked as off-topic.

Sign in to view

forward the bootstrap runner to run-make

272dfe8

The runner was already forwarded to `compiletest`, this just passes it on to `run-make` and uses it in the `run` functions.

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jun 2, 2025

folkertdev force-pushed the run-make-forward-compiletest-runner branch from e3fee6a to 272dfe8 Compare June 2, 2025 17:24

forward the bootstrap runner to run-make #141856

Are you sure you want to change the base?

forward the bootstrap runner to run-make #141856

Uh oh!

Conversation

folkertdev commented Jun 1, 2025 • edited by jieyouxu Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Jun 1, 2025

Uh oh!

jieyouxu left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

jieyouxu commented Jun 1, 2025

Uh oh!

folkertdev commented Jun 1, 2025

Uh oh!

jieyouxu commented Jun 1, 2025

Uh oh!

bors commented Jun 1, 2025

Uh oh!

jieyouxu commented Jun 1, 2025

Uh oh!

rust-bors bot commented Jun 1, 2025

Uh oh!

This comment has been minimized.

bors commented Jun 1, 2025

Uh oh!

This comment has been minimized.

jieyouxu commented Jun 1, 2025

Uh oh!

folkertdev commented Jun 1, 2025

Uh oh!

jieyouxu commented Jun 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jieyouxu commented Jun 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

folkertdev commented Jun 1, 2025

Uh oh!

jieyouxu commented Jun 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment has been minimized.

folkertdev commented Jun 2, 2025

Uh oh!

jieyouxu commented Jun 2, 2025

Uh oh!

This comment was marked as off-topic.

This comment was marked as off-topic.

jieyouxu commented Jun 2, 2025

Uh oh!

rust-bors bot commented Jun 2, 2025

Uh oh!

rust-bors bot commented Jun 2, 2025

Uh oh!

jieyouxu commented Jun 2, 2025

Uh oh!

folkertdev commented Jun 2, 2025

Uh oh!

jieyouxu commented Jun 2, 2025

Uh oh!

folkertdev commented Jun 2, 2025

Uh oh!

jieyouxu commented Jun 4, 2025

Uh oh!

Uh oh!

forward the bootstrap `runner` to `run-make` #141856

forward the bootstrap `runner` to `run-make` #141856

folkertdev commented Jun 1, 2025 •

edited by jieyouxu

Loading

jieyouxu commented Jun 1, 2025 •

edited

Loading

jieyouxu commented Jun 1, 2025 •

edited

Loading

jieyouxu commented Jun 1, 2025 •

edited

Loading