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

Strip unexpected debuginfo from libLLVM.so and librustc_driver.so when not requesting any debuginfo #114305

Merged
merged 5 commits into from
Aug 4, 2023

Conversation

lqd
Copy link
Member

@lqd lqd commented Jul 31, 2023

As seen in #114175 and in this zulip discussion, there's still some small amount of debuginfo in LLVM's shared library on linux, even when not requesting it (nightly CI), coming from libstdc++.

$ readelf --debug-dump=info ~/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/libLLVM-16-rust-1.73.0-nightly.so | grep DW_TAG_compile_unit -A5 | grep DW_AT_comp_dir | cut -d ":" -f 2- | counts
101 counts
(  1)       39 (38.6%, 38.6%):  (indirect string, offset: 0x7): /tmp/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++
(  2)       38 (37.6%, 76.2%):  (indirect string, offset: 0x43fb2): /tmp/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src/c++11
(  3)       23 (22.8%, 99.0%):  (indirect string, offset: 0x18ed8): /tmp/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src/c++98
(  4)        1 ( 1.0%,100.0%):  (indirect string, offset: 0x53f04): /tmp/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src

Similarly, here's librustc_driver.so when not requesting debuginfo from either rustc or the tools (nightly CI), coming e.g. from our LLVM wrapper:

$ readelf --debug-dump=info ~/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/librustc_driver-e534b3a316089f5f.so | grep DW_TAG_compile_unit -A5 | grep DW_AT_comp_dir | cut -d ":" -f 2- | counts
116 counts
(  1)       34 (29.3%, 29.3%):  (indirect string, offset: 0x3c11): /tmp/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++
(  2)       32 (27.6%, 56.9%):  (indirect string, offset: 0x9753c): /tmp/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src/c++11
(  3)       25 (21.6%, 78.4%):  (indirect string, offset: 0x393bd): /tmp/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src/c++98
(  4)       23 (19.8%, 98.3%):  (indirect string, offset: 0x33ed3): /cargo/registry/src/index.crates.io-6f17d22bba15001f/compiler_builtins-0.1.98
(  5)        1 ( 0.9%, 99.1%):  (indirect string, offset: 0xaffff): /rustc/0d95f9132909ae7c5f2456748d0ffd1c3ba4a8e8
(  6)        1 ( 0.9%,100.0%):  (indirect string, offset: 0xb604a): /tmp/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src

To reduce the size of distributed artifacts, this PR strips debuginfo from the LLVM and rustc_driver shared libraries, when:

  • no debuginfo is requested when building LLVM: link-shared is true, optimize is true and release-debuginfo is false
  • no debuginfo is requested when building the rustc driver:
    • debuginfo-level-rustc and debuginfo-level-tools are off.
    • when building with a stage != 0 compiler: since this is about the distributed artifacts, there's no need to do this at other stages.
  • for both: on a x64 linux host and target where strip -g is available and fixes the issue (I don't know how to strip debuginfo from a .dylib on mac). The LLVM BOLTed .so, and librustc_driver.so are big there, and this will help a little. Other targets/hosts can be added in the future if we want to.

#114175 did the same thing unconditionally in opt-dist, prior to BOLTing LLVM. But this should only be used in conjunction with the other config options mentioned above, and which opt-dist doesn't know about. Therefore, it makes more sense as in bootstrap when building LLVM and rustc when applicable and no debuginfo is requested.

This shouldn't interact badly with CI caching builds and artifacts, right?


From the other PR, libLLVM-16-rust-1.73.0-nightly.so prior to #114141:

  • master: 173.13 MiB
  • stripped debuginfo: 165.12 MiB (-8 MiB, -4.6%)

libLLVM-16-rust-1.73.0-nightly.so after #114141:

  • master: 121.13 MiB
  • stripped debuginfo: 113.12 MiB (still -8 MiB, -6.6%)

librustc_driver.so:

  • master: 118.58 MiB
  • stripped debuginfo: 106.46 MiB (-12 MiB, -10.2%)

(Results are also available in this most recent perf run's artifact sizes)

@rustbot
Copy link
Collaborator

rustbot commented Jul 31, 2023

r? @ozkanonur

(rustbot has picked a reviewer for you, use r? to override)

@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 Jul 31, 2023
@rustbot
Copy link
Collaborator

rustbot commented Jul 31, 2023

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

src/bootstrap/compile.rs Outdated Show resolved Hide resolved
@onur-ozkan
Copy link
Member

@bors r+ rollup

@bors
Copy link
Contributor

bors commented Aug 3, 2023

📌 Commit c98c512 has been approved by ozkanonur

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 3, 2023
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Aug 3, 2023
Strip unexpected debuginfo from `libLLVM.so` and `librustc_driver.so` when not requesting any debuginfo

As seen in rust-lang#114175 and in [this zulip discussion](https://rust-lang.zulipchat.com/#narrow/stream/247081-t-compiler.2Fperformance/topic/Artifact.20sizes/near/379302655), there's still some small amount of debuginfo in LLVM's shared library on linux, even when not requesting it (nightly CI), coming from `libstdc++`.

```
$ readelf --debug-dump=info ~/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/libLLVM-16-rust-1.73.0-nightly.so | grep DW_TAG_compile_unit -A5 | grep DW_AT_comp_dir | cut -d ":" -f 2- | counts
101 counts
(  1)       39 (38.6%, 38.6%):  (indirect string, offset: 0x7): /tmp/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++
(  2)       38 (37.6%, 76.2%):  (indirect string, offset: 0x43fb2): /tmp/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src/c++11
(  3)       23 (22.8%, 99.0%):  (indirect string, offset: 0x18ed8): /tmp/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src/c++98
(  4)        1 ( 1.0%,100.0%):  (indirect string, offset: 0x53f04): /tmp/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src
```

Similarly, here's `librustc_driver.so` when not requesting debuginfo from either rustc or the tools (nightly CI), coming e.g. from our LLVM wrapper:
```
$ readelf --debug-dump=info ~/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/librustc_driver-e534b3a316089f5f.so | grep DW_TAG_compile_unit -A5 | grep DW_AT_comp_dir | cut -d ":" -f 2- | counts
116 counts
(  1)       34 (29.3%, 29.3%):  (indirect string, offset: 0x3c11): /tmp/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++
(  2)       32 (27.6%, 56.9%):  (indirect string, offset: 0x9753c): /tmp/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src/c++11
(  3)       25 (21.6%, 78.4%):  (indirect string, offset: 0x393bd): /tmp/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src/c++98
(  4)       23 (19.8%, 98.3%):  (indirect string, offset: 0x33ed3): /cargo/registry/src/index.crates.io-6f17d22bba15001f/compiler_builtins-0.1.98
(  5)        1 ( 0.9%, 99.1%):  (indirect string, offset: 0xaffff): /rustc/0d95f9132909ae7c5f2456748d0ffd1c3ba4a8e8
(  6)        1 ( 0.9%,100.0%):  (indirect string, offset: 0xb604a): /tmp/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src
```

To reduce the size of distributed artifacts, this PR strips debuginfo from the LLVM and `rustc_driver` shared libraries, when:
- no debuginfo is requested when building LLVM: `link-shared` is true, `optimize` is true and `release-debuginfo` is false
- no debuginfo is requested when building the rustc driver:
  - `debuginfo-level-rustc` and `debuginfo-level-tools` are off.
  - when building with a stage != 0 compiler: since this is about the distributed artifacts, there's no need to do this at other stages.
- for both: on a x64 linux host and target where `strip -g` is available and fixes the issue (I don't know how to strip debuginfo from a `.dylib` on mac). The LLVM BOLTed .so, and `librustc_driver.so` are big there, and this will help a little. Other targets/hosts can be added in the future if we want to.

rust-lang#114175 did the same thing unconditionally in `opt-dist`, prior to BOLTing LLVM. But this should only be used in conjunction with the other config options mentioned above, and which `opt-dist` doesn't know about. Therefore, it makes more sense as in bootstrap when building LLVM and rustc when applicable and no debuginfo is requested.

This shouldn't interact badly with CI caching builds and artifacts, right?

---

From the other PR, `libLLVM-16-rust-1.73.0-nightly.so` prior to rust-lang#114141:
- master: 173.13 MiB
- stripped debuginfo: 165.12 MiB (-8 MiB, -4.6%)

`libLLVM-16-rust-1.73.0-nightly.so` after rust-lang#114141:
- master: 121.13 MiB
- stripped debuginfo: 113.12 MiB (still -8 MiB, -6.6%)

`librustc_driver.so`:
- master: 118.58 MiB
- stripped debuginfo: 106.46 MiB (-12 MiB, -10.2%)

(Results are also available in this most recent [perf run's artifact sizes](https://perf.rust-lang.org/compare.html?start=b321edd1b2d4bd00c7b4611e8f20a03ee7b77023&end=810ab570d5d27facb91806e5d9847815d9dac22a&stat=instructions%3Au&tab=artifact-size))
@matthiaskrgr
Copy link
Member

@bors rollup=never

@bors
Copy link
Contributor

bors commented Aug 4, 2023

⌛ Testing commit c98c512 with merge a7caaae...

@bors
Copy link
Contributor

bors commented Aug 4, 2023

☀️ Test successful - checks-actions
Approved by: ozkanonur
Pushing a7caaae to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Aug 4, 2023
@bors bors merged commit a7caaae into rust-lang:master Aug 4, 2023
11 checks passed
@rustbot rustbot added this to the 1.73.0 milestone Aug 4, 2023
@lqd lqd deleted the bootstrap-strip branch August 4, 2023 08:41
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (a7caaae): comparison URL.

Overall result: ❌✅ regressions and improvements - no action needed

@rustbot label: -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
0.2% [0.2%, 0.2%] 1
Improvements ✅
(primary)
-0.2% [-0.2%, -0.2%] 2
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) -0.2% [-0.2%, -0.2%] 2

Max RSS (memory usage)

Results

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% [3.2%, 3.2%] 1
Regressions ❌
(secondary)
3.1% [3.1%, 3.1%] 1
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 3.2% [3.2%, 3.2%] 1

Cycles

Results

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)
- - 0
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-2.7% [-4.1%, -2.0%] 9
All ❌✅ (primary) - - 0

Binary size

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

Bootstrap: 649.049s -> 647.584s (-0.23%)

Dylan-DPC added a commit to Dylan-DPC/rust that referenced this pull request Aug 8, 2023
Prevent constant rebuilds of `rustc-main` (and thus everything else)

PR rust-lang#114305 changed bootstrap to run `strip -g` on `librustc_driver.so` and `libllvm.so` on Linux when no debuginfo was requested. Unfortunately, that PR resulted in bootstrap always rebuilding everything starting from stage 1 `rustc-main` (including stage 1 libraries and tests) when invoking bootstrap multiple times.

We noticed this because Ferrocene's CI times increased to between 2x and 3x total execution time, but the regression can also be reproduced locally by running `./x build library/sysroot --stage 1` twice.

The explanation of the problem is in the code comments.

r? `@lqd`
cc `@ozkanonur`
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Aug 8, 2023
Prevent constant rebuilds of `rustc-main` (and thus everything else)

PR rust-lang#114305 changed bootstrap to run `strip -g` on `librustc_driver.so` and `libllvm.so` on Linux when no debuginfo was requested. Unfortunately, that PR resulted in bootstrap always rebuilding everything starting from stage 1 `rustc-main` (including stage 1 libraries and tests) when invoking bootstrap multiple times.

We noticed this because Ferrocene's CI times increased to between 2x and 3x total execution time, but the regression can also be reproduced locally by running `./x build library/sysroot --stage 1` twice.

The explanation of the problem is in the code comments.

r? ``@lqd``
cc ``@ozkanonur``
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Aug 8, 2023
Prevent constant rebuilds of `rustc-main` (and thus everything else)

PR rust-lang#114305 changed bootstrap to run `strip -g` on `librustc_driver.so` and `libllvm.so` on Linux when no debuginfo was requested. Unfortunately, that PR resulted in bootstrap always rebuilding everything starting from stage 1 `rustc-main` (including stage 1 libraries and tests) when invoking bootstrap multiple times.

We noticed this because Ferrocene's CI times increased to between 2x and 3x total execution time, but the regression can also be reproduced locally by running `./x build library/sysroot --stage 1` twice.

The explanation of the problem is in the code comments.

r? ```@lqd```
cc ```@ozkanonur```
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
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)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants