This is a cache of https://lobste.rs/s/ukn1u3/faster_linking_times_with_1_90_0_stable_on. It is a snapshot of the page as it appeared on 2025-09-03T16:28:06.052+0200.
Faster linking times with 1.90.0 stable on <strong>linux</strong> using the LLD linker | Lobsters
Funnily enough, just last week I ran into a weird/horrible truth: apparently GNU Gold, LLVM LLD, and the mold linker all GC out the linux SystemTap tracing library’s .stapsdt.base ELF section which is needed for SystemTap USDTs (user-space statically defined tracepoints) to work properly, assuming that the section is unneeded since it is an allocated (runtime) section that is only referred to from non-allocated sections. Depending on the tracing application, this lack of the .stapsdt.base section leads to either probes not firing (this happens with bpftrace) or to the whole target application crashing (this happens with linux perf) due to the probe addresses effectively becoming corrupted.
So, best as I can tell, USDTs on linux have never worked on any linker except GNU ld. I was quite shocked to learn this.
What’s the status of lld on Windows? It would be great if the Rust toolchain was self-contained on Windows without having to get a linker from Microsoft.
I’ve been using lld-link.exe for smaller programs, but ran into a miscompilation with Zed on the C/Rust FFI boundary recently where the symbol table had the wrong symbol at a particular address. Switching back to MSVC’s link.exe fixed it, at the cost of a large compile perf regression.
Funnily enough, just last week I ran into a weird/horrible truth: apparently GNU Gold, LLVM LLD, and the mold linker all GC out the linux SystemTap tracing library’s
.stapsdt.baseELF section which is needed for SystemTap USDTs (user-space statically defined tracepoints) to work properly, assuming that the section is unneeded since it is an allocated (runtime) section that is only referred to from non-allocated sections. Depending on the tracing application, this lack of the.stapsdt.basesection leads to either probes not firing (this happens with bpftrace) or to the whole target application crashing (this happens with linux perf) due to the probe addresses effectively becoming corrupted.So, best as I can tell, USDTs on linux have never worked on any linker except GNU ld. I was quite shocked to learn this.
What’s the status of lld on Windows? It would be great if the Rust toolchain was self-contained on Windows without having to get a linker from Microsoft.
I’ve been using lld-link.exe for smaller programs, but ran into a miscompilation with Zed on the C/Rust FFI boundary recently where the symbol table had the wrong symbol at a particular address. Switching back to MSVC’s link.exe fixed it, at the cost of a large compile perf regression.
Sorry, I should have added this is on Windows ARM, which is probably less mature than x86_64.
I use lld via:
Interesting, wonder if it avoids the bug that I ran into with lld-link.exe.
The Zed miscomp? I’d be pretty surprised if it fixed it, but worth a shot I suppose.
Along similar lines, I was trying to use linkme last weekend and it was not working with rust-lld :(
I’ve been looking forward to this!