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

Enable zstd for debug compression. #125642

Merged
merged 4 commits into from
Aug 10, 2024
Merged

Enable zstd for debug compression. #125642

merged 4 commits into from
Aug 10, 2024

Conversation

khuey
Copy link
Contributor

@khuey khuey commented May 28, 2024

Set LLVM_ENABLE_ZSTD alongside LLVM_ENABLE_ZLIB so that --compress-debug-sections=zstd is an option.

See #120953

try-job: x86_64-gnu-tools

@rustbot
Copy link
Collaborator

rustbot commented May 28, 2024

r? @onur-ozkan

rustbot has assigned @onur-ozkan.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@rustbot rustbot added 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 May 28, 2024
@khuey
Copy link
Contributor Author

khuey commented May 28, 2024

To elaborate a bit here, in #99464 LLVM was updated to version 15, the first to have LLVM_ENABLE_ZSTD. That was explicitly disabled (to avoid pulling in a dependency, according to the PR).

That was fine until #124129 made rust-lld the default linker. Now, because LLVM_ENABLE_ZSTD=OFF disables --compress-debug-sections=zstd, rust-lld is (potentially) a regression against the system linker.

So here I'd like to turn this on so rust-lld and thus the out of the box default is at least as capable as the system linker here.

@khuey khuey marked this pull request as ready for review May 28, 2024 04:35
@rustbot
Copy link
Collaborator

rustbot commented May 28, 2024

This PR changes how LLVM is built. Consider updating src/bootstrap/download-ci-llvm-stamp.

@lqd
Copy link
Member

lqd commented May 28, 2024

How are you producing this zstd-compressed debuginfo without building your own rustc/llvm to add zstd support in -Zdebuginfo-compression?

@khuey
Copy link
Contributor Author

khuey commented May 28, 2024

-C link-arg=-Wl,--compress-debug-sections=zstd

@lqd
Copy link
Member

lqd commented May 28, 2024

That's what I expected, and it feels suboptimal that rustc/llvm think zstd compression is disabled here: we could disable self-contained linking in that case, or could have emitted a warning/error. I'm sure you're already aware that the linker change is easily controllable without more link args, to fall back to system lld (-Clink-self-contained=-linker -Zunstable-options) or bfd (-Zlinker-features=-lld).

@khuey
Copy link
Contributor Author

khuey commented May 28, 2024

It does emit an error: note: rust-lld: error: --compress-debug-sections: LLVM was not built with LLVM_ENABLE_ZSTD or did not find zstd at build time

I'm aware that I can explicitly opt into the system linker, but this is trivial to fix in rust-lld so I feel we may as well fix it so things just work.

@lqd
Copy link
Member

lqd commented May 28, 2024

but this is trivial to fix in rust-lld so I feel we may as well fix it so things just work

I'm aware and I agree, I just don't know the rationale in bootstrap yet, so there may be concerns about adding the dependency and we'll have to wait for more info from t-bootstrap / infra.

@workingjubilee
Copy link
Member

@nikic was the one who toggled this off. Based on the comments at the time, am I correct in I believing there was no particular reason beyond "let's not accidentally depend on libzstd.so"? Thus it should be fine to do it as long as we are doing it on purpose?

@nikic
Copy link
Contributor

nikic commented May 28, 2024

@nikic was the one who toggled this off. Based on the comments at the time, am I correct in I believing there was no particular reason beyond "let's not accidentally depend on libzstd.so"? Thus it should be fine to do it as long as we are doing it on purpose?

I think we still wouldn't want a dependency on libzstd.so, which probably has a non-negligible chance of not being already installed? If we enable zstd we should probably statically link it.

@workingjubilee
Copy link
Member

Okay, "we want everything to just be rolled up into our LLVM" sounds fine to me.

Comment on lines 377 to 383
// Disable zstd to avoid a dependency on libzstd.so.
cfg.define("LLVM_ENABLE_ZSTD", "OFF");

// Libraries for ELF compression.
if !target.is_windows() {
cfg.define("LLVM_ENABLE_ZLIB", "ON");
cfg.define("LLVM_ENABLE_ZSTD", "ON");
} else {
cfg.define("LLVM_ENABLE_ZLIB", "OFF");
cfg.define("LLVM_ENABLE_ZSTD", "OFF");
Copy link
Member

@onur-ozkan onur-ozkan May 28, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about making this configurable in config.toml (off by default) instead of constantly setting it as "ON" ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The point of this PR to enable it by default. If it's not enabled by default it's easier to disable the self-contained linker than to build rustc, including LLVM, from scratch.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do not understand why we would make something configurable without a specific reason to do so.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doesn't this require an additional dependency to be installed? Also, according to the LLVM docs when it's not set LLVM build enables zstd only if it exists on the system. Could that be an option here?

Fwiw using "FORCE_ON" makes the build raise a hard error when zstd can't be found on the system.

ref: https://llvm.org/docs/CMake.html

Copy link
Member

@workingjubilee workingjubilee May 29, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doesn't this require an additional dependency to be installed?

Raising the requirements to build our LLVM recipe seems fine given that we support using an external LLVM. Thus we can't assume that the external LLVM has zlib or zstd support (as both are optional) and must query it at runtime (which we do), and we support building an LLVM with arbitrary configuration already: just bring your own.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doesn't this require an additional dependency to be installed?

As the patch stands today, it requires libzstd.so to be available at runtime if libzstd was available at build time. It doesn't actually require libzstd to be available at build time (because it uses ON instead of FORCE_ON).

There's a matrix of possible outcomes here.

ON FORCE_ON
No LLVM_USE_STATIC_ZSTD Not required at build time, required at runtime if present at build time, silently disabled if not present at build time Required at build time and runtime
LLVM_USE_STATIC_ZSTD Not required at build time or runtime, silently disabled if not present at build time Required at build time, not at runtime

Where we're currently in the top left cell.

@onur-ozkan onur-ozkan 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 May 28, 2024
@onur-ozkan
Copy link
Member

If we enable zstd we should probably statically link it.

Once this is done, I am okay with landing it.

@khuey
Copy link
Contributor Author

khuey commented May 29, 2024

Unfortunately statically linking zstd is not currently as simple as setting LLVM_USE_STATIC_ZSTD=True. llvm-config outputs the flags for dynamic linking regardless of the value of LLVM_USE_STATIC_ZSTD.

@khuey
Copy link
Contributor Author

khuey commented May 30, 2024

Alright with llvm/llvm-project#93754 and those two additional changesets everything gets linked statically.

@onur-ozkan
Copy link
Member

r? compiler

@rustbot rustbot added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label May 30, 2024
@rustbot rustbot assigned fee1-dead and unassigned onur-ozkan May 30, 2024
@onur-ozkan onur-ozkan 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 May 30, 2024
@fee1-dead
Copy link
Member

r? compiler

@bors
Copy link
Contributor

bors commented Aug 9, 2024

☀️ Try build successful - checks-actions
Build commit: f568b13 (f568b137b285620fa919275d76c5c02e76baa796)

@Kobzol
Copy link
Contributor

Kobzol commented Aug 9, 2024

Okay, seems to work now. The commit history now contains some reverts though, maybe it wouldn't be such a bad idea to clean it up a little. Could you please compress it down to a smaller number of commits? Thank you.

Set LLVM_ENABLE_ZSTD alongside LLVM_ENABLE_ZLIB so that --compress-debug-sections=zstd is an option.
Use static linking to avoid a new runtime dependency. Add an llvm.libzstd bootstrap option for LLVM
with zstd. Set it off by default except for the dist builder. Handle llvm-config --system-libs output
that contains static libraries.
Build libzstd from source because the EPEL package is built without fPIC.
@khuey
Copy link
Contributor Author

khuey commented Aug 9, 2024

I reorganized these into something halfway sensible.

Time for yet another try run!

@Kobzol
Copy link
Contributor

Kobzol commented Aug 9, 2024

Thanks. Let's try again.

@bors r+

@bors
Copy link
Contributor

bors commented Aug 9, 2024

📌 Commit 8db318c has been approved by Kobzol

It is now in the queue for this repository.

@bors 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 Aug 9, 2024
@bors
Copy link
Contributor

bors commented Aug 9, 2024

⌛ Testing commit 8db318c with merge 4029c72...

bors added a commit to rust-lang-ci/rust that referenced this pull request Aug 9, 2024
Enable zstd for debug compression.

Set LLVM_ENABLE_ZSTD alongside LLVM_ENABLE_ZLIB so that --compress-debug-sections=zstd is an option.

See rust-lang#120953

try-job: x86_64-gnu-tools
@rust-log-analyzer
Copy link
Collaborator

The job i686-mingw failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)
---- [run-make] tests\run-make\dump-ice-to-disk stdout ----

error: rmake recipe failed to complete
status: exit code: 101
command: "C:\\a\\rust\\rust\\build\\i686-pc-windows-gnu\\test\\run-make\\dump-ice-to-disk\\rmake.exe"
--- stderr -------------------------------
thread 'main' panicked at C:\a\rust\rust\tests\run-make\dump-ice-to-disk\rmake.rs:32:5:
assertion `left == right` failed
  left: 59

@bors
Copy link
Contributor

bors commented Aug 9, 2024

💔 Test failed - checks-actions

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Aug 9, 2024
@Kobzol
Copy link
Contributor

Kobzol commented Aug 9, 2024

That failure is not related to this PR.

@bors retry

@bors 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 Aug 9, 2024
@bors
Copy link
Contributor

bors commented Aug 9, 2024

⌛ Testing commit 8db318c with merge 68d2e8a...

@bors
Copy link
Contributor

bors commented Aug 10, 2024

☀️ Test successful - checks-actions
Approved by: Kobzol
Pushing 68d2e8a to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Aug 10, 2024
@bors bors merged commit 68d2e8a into rust-lang:master Aug 10, 2024
7 checks passed
@rustbot rustbot added this to the 1.82.0 milestone Aug 10, 2024
@khuey
Copy link
Contributor Author

khuey commented Aug 10, 2024

Huzzah!

Thanks everyone.

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (68d2e8a): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results (primary 3.2%, secondary 0.3%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
3.2% [1.5%, 5.0%] 2
Regressions ❌
(secondary)
2.1% [2.1%, 2.1%] 1
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-1.6% [-1.6%, -1.6%] 1
All ❌✅ (primary) 3.2% [1.5%, 5.0%] 2

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 760.743s -> 762.964s (0.29%)
Artifact size: 337.11 MiB -> 339.32 MiB (0.66%)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
-Zdebuginfo-compression Unstable option: debuginfo compression A-run-make Area: port run-make Makefiles to rmake.rs A-testsuite Area: The testsuite used to check the correctness of rustc merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-infra Relevant to the infrastructure team, which will review and decide on the PR/issue.
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.