Implement `ToolTarget` and port `RemoteTestServer` and `WasmComponentLd` to it #143581

Kobzol · 2025-07-07T11:30:47Z

We have a set of tools (such as the various linker wrappers - LLD/WASM/LLVM linkers) that behave like bootstrap tools when not cross-compiling, and like std tools when cross-compiling. Before, various modes were used for them (currently - ModeStd for WasmComponentLd and LldWrapper and ToolRustc for LlvmBitcodeLinker). This was wasteful, if you did a stage 2 non-cross-compiled build, WasmComponentLd would be built twice, even though we can just build it once using the stage0 compiler.

I would like to unify these. This PR is the first step towards that. I started what I considered to be the simplest linker step out of the three.

r? @jieyouxu

…ith the stage0 compiler

This avoid needless rebuilds when the tool can be simply compiled by the stage0 compiler.

src/bootstrap/src/core/build_steps/tool.rs

bjorn3 · 2025-07-07T12:42:25Z

I don't think cross-compiling should result in a different binary at stage2 that native compilation. Nor should a local rebuild (using the current rustc version as bootstrap compiler) result in a different binary at stage2 than using the previous rustc version as bootstrap compiler.

jieyouxu

Thanks, I think this design seems like a "most correct" approach to address the nuisance of these tools. I do have a question.

jieyouxu · 2025-07-07T13:01:48Z

src/bootstrap/src/core/build_steps/tool.rs

@@ -196,7 +196,7 @@ impl Step for ToolBuild {
            Kind::Build,
            self.mode,
            self.tool,
-            self.build_compiler.stage,
+            self.build_compiler.stage + 1,


Remark: this is because it's a product of the stage 0 rustc that is not the stage 0 library

jieyouxu · 2025-07-07T13:05:08Z

src/bootstrap/src/core/build_steps/tool.rs

 /// Returns a compiler that is able to compile a `ToolTarget` tool for the given `target`.
 pub(crate) fn get_tool_target_compiler(builder: &Builder<'_>, target: TargetSelection) -> Compiler {


Question: this isn't quite obvious, because in the cross-compile case, we'll also have to ensure target std as a side-effect, right? I don't have a better name for this just yet, so not a blocker.

I can see why we might want to have some kind of "proof of std artifacts getting built".

Yes, that would indeed be nice, but that's a massive refactoring. I'm continuously thinking about how to approach it. The attachment of a std to Compiler in bootstrap is currently fully implicit, so this just does what the rest of bootstrap does.

Yeah, this was more of a question, and not a blocking change request.

jieyouxu · 2025-07-07T13:10:21Z

src/bootstrap/src/core/build_steps/tool.rs

+            extra_features: vec![],
+            allow_features: "min-specialization",


Question: hm, might this be a problem if min_specialization ever gets renamed, removed or stabilized? Or rather, the tool now has to be support being built by both stage 0 compiler and stage 1 compiler right? In that situation, the tool would have to cfg(bootstrap) anyway I think.

I don't think the feature flag is even needed, the tool compiles with the stable compiler... Unless it does some weird detection in build scripts.

I would keep it for now, to leave the previous functionality intact. If it becomes an issue, we can always try to remove it.

Sure, that sounds reasonable.

jieyouxu · 2025-07-07T13:16:57Z

I don't think cross-compiling should result in a different binary at stage2 that native compilation. Nor should a local rebuild (using the current rustc version as bootstrap compiler) result in a different binary at stage2 than using the previous rustc version as bootstrap compiler.

Hm, as in with this scheme, we would be producing different wasm-component-ld depending on whether it was compiled "for host" or "for target" right?

bjorn3 · 2025-07-07T13:18:54Z

Hm, as in with this scheme, we would be producing different wasm-component-ld depending on whether it was compiled "for host" or "for target" right?

Yes. And in case it was compiled for the host a local rebuild won't produce an identical executable to a regular bootstrap. The local rebuild case matches when it was compiled for the target.

Kobzol · 2025-07-07T13:24:37Z

Hm, as in with this scheme, we would be producing different wasm-component-ld depending on whether it was compiled "for host" or "for target" right?

Yes. And in case it was compiled for the host a local rebuild won't produce an identical executable to a regular bootstrap. The local rebuild case matches when it was compiled for the target.

But that is the point, right? If we compile rustc for foo, we need to produce wasm-component-ld for foo (not for host), because the rustc will be executing this binary on its host platform. Or not?

bjorn3 · 2025-07-07T13:31:16Z

I would expect cross-compiling from bar -> foo to produce the exact same executable as compiling natively on foo. Choosing between compiling with the bootstrap compiler and compiling with the local rustc depending on if you are cross-compiling or not causes both cases to produce different executables.

Kobzol · 2025-07-07T13:41:32Z

I would expect cross-compiling from bar -> foo to produce the exact same executable as compiling natively on foo. Choosing between compiling with the bootstrap compiler and compiling with the local rustc depending on if you are cross-compiling or not causes both cases to produce different executables.

Hmm, I see what you mean now. It seems like a noble goal, but do we actually uphold it in practice? I would be very much surprised if bootstrap managed to cross-compile 1:1 bitwise exact binaries, and we don't have tests for this, definitely not for the linker tools. We were also already compiling wasm-component-ld using the stage0 compiler before, we just recompiled it again using the stage1 compiler when doing a stage2 (or cross-compiling) build.

More generally, these should be "normal" Rust tools compilable by a stable compiler. Does it matter so much with what compiler we build them?

bjorn3 · 2025-07-07T13:45:25Z

We were also already compiling wasm-component-ld using the stage0 compiler before, we just recompiled it again using the stage1 compiler when doing a stage2 (or cross-compiling) build.

We only distribute the stage2 build. It is expected that the stage1 build doesn't exactly match.

It seems like a noble goal, but do we actually uphold it in practice? I would be very much surprised if bootstrap managed to cross-compile 1:1 bitwise exact binaries, and we don't have tests for this, definitely not for the linker tools.

I don't think we currently do it perfectly (especially for cross-compilation), but that doesn't mean we should make it worse. Having cross-compilation produce identical executables is maybe not the most important, but I do think local-rebuild should produce identical executables.

Kobzol · 2025-07-07T13:52:43Z

Hmm, that's unfortunate. We spend ~2 minutes building just WasmComponentLd on each CI dist build that has it enabled, and needlessly recompile it a bunch of times. This was a relatively easy way of reducing that compilation count.

Another alternative would be to distinguish in bootstrap if tools are needed for the intermediate stages, and if not, then skip building them (e.g. if we do a stage 2 build, don't build wasm-component-ld for stage 1 rustc). But that's either a large refactoring or piling more hacks on top of the Assemble step..

but I do think local-rebuild should produce identical executables.

Could you expand on this a bit more? We don't ever use local rebuild for dist builders (right?), and if you compile a "stage 0 bootstrap tool", e.g. opt-dist with local rebuild enabled, it will be different anyway. Why is it so important for WasmComponentLd specifically to be the same? Because we dist it?

bjorn3 · 2025-07-07T14:32:06Z

Could you expand on this a bit more? We don't ever use local rebuild for dist builders (right?),

Distros do use local rebuild.

and if you compile a "stage 0 bootstrap tool", e.g. opt-dist with local rebuild enabled, it will be different anyway. Why is it so important for WasmComponentLd specifically to be the same? Because we dist it?

Yes, it doesn't really matter for local tools, only for distributed tools.

I believe cargo already has this issue now that I think about it, so I guess this PR doesn't make the problem much worse. So I withdraw my concern about this PR.

Kobzol · 2025-07-07T14:35:45Z

Yeah, since cargo is also compilable by stage0, I wanted to turn it into ToolTarget too. Currently it's ToolRustc, but that's not really needed, as far as I understand.

Well, your concerns are quite interesting, I haven't thought of that. And this PR does add more complexity to bootstrap, although it also makes the behavior of the "target" tools more precise and unified, before they were using ModeStd, ModeBootstrap, ModeRustc kind of randomly.

I would try to land this and see if anyone complaints about the non-identical binaries. I personally expect that our cross-compiles are far from identical anyway though, and that even local rebuild had some issues around this previously. If someone finds this to be an issue, we can still keep the more accurate tool mode, and just revert the change to compile with stage0.

jieyouxu

Thanks, the changes look good to me. One comment request re. the reproducibility consideration so a Future Reader ™️ has some more context.

jieyouxu · 2025-07-08T05:12:30Z

src/bootstrap/src/lib.rs

+    /// Build a cross-compilable helper tool.
+    /// - If we compile it for the host, we use the stage0 compiler.
+    /// - If we compile it for another target, we use local compiler (because stage0 does not have
+    ///   stdlib for the tool available for other targets).
+    ///
+    /// This mode exists to avoid needless (re)builds of tools that can be compiled with
+    /// a stable/stage0 compiler. It essentially behaves as `ToolBootstrap` when not
+    /// cross-compiling, and as `ToolStd` when cross-compiling.
+    ///
+    /// It is used e.g. for linkers and linker tools invoked by rustc on its host target.
+    ///
+    /// These tools participate in staging only when required for cross-compilation.
+    ToolTarget,


Suggestion: can you leave a comment here about the interesting reproducibility question (that we considered it, but decided that it still seems worth trying this approach) re. we would not be producing the same tool as we use different compilers when the tool is built for host vs for target?

jieyouxu · 2025-07-08T06:32:17Z

@rustbot author

Kobzol · 2025-07-08T07:10:23Z

Done.

@rustbot ready

jieyouxu · 2025-07-08T07:13:47Z

Thanks.
@bors r+ rollup=never (interesting tool changes)

bors · 2025-07-08T07:13:50Z

📌 Commit 5c85adc has been approved by jieyouxu

It is now in the queue for this repository.

Kobzol · 2025-07-08T08:03:01Z

@bors r-

sigh

Kobzol · 2025-07-08T08:51:54Z

I want to get a bit more opinions on this.

Kobzol · 2025-07-08T09:14:46Z

In addition to the non-identical binaries for cross-compilation and local rebuilds, this would mean that we can't easily ship security fixes to these tools when we dist them. That's not good.

Kobzol added 4 commits July 7, 2025 12:25

Rename compiler to build_compiler

e8be2d8

Introduce ToolTarget for cross-compilable tools that can be built w…

63f7241

…ith the stage0 compiler

Port RemoteTestServer to ToolTarget

1239b99

Make WasmComponentLd a ToolTarget tool

46851d3

This avoid needless rebuilds when the tool can be simply compiled by the stage0 compiler.

rustbot assigned jieyouxu Jul 7, 2025

rustbot added A-testsuite Area: The testsuite used to check the correctness of rustc S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) labels Jul 7, 2025

jieyouxu reviewed Jul 7, 2025

View reviewed changes

src/bootstrap/src/core/build_steps/tool.rs Show resolved Hide resolved

Kobzol added 2 commits July 7, 2025 14:15

Handle ToolTarget when setting RUSTC_FORCE_UNSTABLE

759366b

Use raw stage0 sysroot for ToolTarget tools

51d48f0

jieyouxu reviewed Jul 7, 2025

View reviewed changes

jieyouxu approved these changes Jul 8, 2025

View reviewed changes

rustbot 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 Jul 8, 2025

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 Jul 8, 2025

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 8, 2025

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-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jul 8, 2025

Add cross-complation comment

4fddfd1

Kobzol force-pushed the tool-wasm-component-ld branch from 5c85adc to 4fddfd1 Compare July 8, 2025 08:03

Kobzol marked this pull request as draft July 8, 2025 08:51

Kobzol closed this Jul 8, 2025

		/// Returns a compiler that is able to compile a `ToolTarget` tool for the given `target`.
		pub(crate) fn get_tool_target_compiler(builder: &Builder<'_>, target: TargetSelection) -> Compiler {

		extra_features: vec![],
		allow_features: "min-specialization",

Implement ToolTarget and port RemoteTestServer and WasmComponentLd to it #143581

Implement ToolTarget and port RemoteTestServer and WasmComponentLd to it #143581

Conversation

Kobzol commented Jul 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

bjorn3 commented Jul 7, 2025

Uh oh!

jieyouxu left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

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

Uh oh!

Uh oh!

bjorn3 commented Jul 7, 2025

Uh oh!

Kobzol commented Jul 7, 2025

Uh oh!

bjorn3 commented Jul 7, 2025

Uh oh!

Kobzol commented Jul 7, 2025

Uh oh!

bjorn3 commented Jul 7, 2025

Uh oh!

Kobzol commented Jul 7, 2025

Uh oh!

bjorn3 commented Jul 7, 2025

Uh oh!

Kobzol commented Jul 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jieyouxu left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jieyouxu commented Jul 8, 2025

Uh oh!

Kobzol commented Jul 8, 2025

Uh oh!

jieyouxu commented Jul 8, 2025

Uh oh!

bors commented Jul 8, 2025

Uh oh!

This comment has been minimized.

Kobzol commented Jul 8, 2025

Uh oh!

Kobzol commented Jul 8, 2025

Uh oh!

Kobzol commented Jul 8, 2025

Uh oh!

Uh oh!

Implement `ToolTarget` and port `RemoteTestServer` and `WasmComponentLd` to it #143581

Implement `ToolTarget` and port `RemoteTestServer` and `WasmComponentLd` to it #143581

Kobzol commented Jul 7, 2025 •

edited

Loading

jieyouxu commented Jul 7, 2025 •

edited

Loading

Kobzol commented Jul 7, 2025 •

edited

Loading

jieyouxu left a comment •

edited

Loading