Preserve the .debug_gdb_scripts section #143679

sebastianpoeplau · 2025-07-09T11:40:46Z

Make sure that compiler and linker don't optimize the section's contents
away by adding the global holding the data to llvm.used. This
eliminates the need for a volatile load in the main shim; since the LLVM
codegen backend is the only implementer of the corresponding trait
function, remove it entirely.

Pretty printers in dylib dependencies are now emitted by the main crate
instead of the dylib; apart from matching how rlibs are handled, this
approach has the advantage that omit_gdb_pretty_printer_section keeps
working with dylib dependencies.

r? @bjorn3

rustbot · 2025-07-09T11:40:53Z

Some changes occurred in compiler/rustc_codegen_ssa

cc @WaffleLapkin

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo, @GuillaumeGomez

compiler/rustc_codegen_llvm/src/debuginfo/gdb.rs

compiler/rustc_codegen_gcc/src/debuginfo.rs

tests/codegen/gdb_debug_script_load.rs

bjorn3 · 2025-07-09T13:27:04Z

@bors r+

bors · 2025-07-09T13:27:08Z

📌 Commit d54c3ea has been approved by bjorn3

It is now in the queue for this repository.

…b-scripts-section, r=bjorn3 Preserve the .debug_gdb_scripts section Make sure that compiler and linker don't optimize the section's contents away by adding the global holding the data to `llvm.used`. This eliminates the need for a volatile load in the main shim; since the LLVM codegen backend is the only implementer of the corresponding trait function, remove it entirely. r? `@bjorn3`

…b-scripts-section, r=bjorn3 Preserve the .debug_gdb_scripts section Make sure that compiler and linker don't optimize the section's contents away by adding the global holding the data to `llvm.used`. This eliminates the need for a volatile load in the main shim; since the LLVM codegen backend is the only implementer of the corresponding trait function, remove it entirely. r? ``@bjorn3``

Rollup of 8 pull requests Successful merges: - #140136 (Add an aarch64-msvc build running on ARM64 Windows) - #143642 (stdarch subtree update) - #143679 (Preserve the .debug_gdb_scripts section) - #143707 (Fix `--skip-std-check-if-no-download-rustc`) - #143722 (Make some "safe" llvm ops actually sound) - #143728 (Resolve refactor: extraction of `finalize_module_binding` and `single_import_can_define_name`) - #143742 (Rework borrowing suggestions to use `Expr` instead of just `Span`) - #143744 (Properly track the depth when expanding free alias types) r? `@ghost` `@rustbot` modify labels: rollup

tgross35 · 2025-07-11T00:19:45Z

Looks like some GDB tests failed #143755 (comment)
@bors r-
@bors2 try jobs=dist-i586-gnu-i586-i686-musl

…ection, r=<try> Preserve the .debug_gdb_scripts section Make sure that compiler and linker don't optimize the section's contents away by adding the global holding the data to `llvm.used`. This eliminates the need for a volatile load in the main shim; since the LLVM codegen backend is the only implementer of the corresponding trait function, remove it entirely. r? `@bjorn3` try-job: dist-i586-gnu-i586-i686-musl

rust-bors · 2025-07-11T00:19:50Z

⌛ Trying commit d54c3ea with merge f7ba1a6…

To cancel the try build, run the command @bors2 try cancel.

rust-bors · 2025-07-11T01:30:37Z

💔 Test failed

CI ❌

sebastianpoeplau · 2025-07-11T08:00:37Z

Looks like some GDB tests failed #143755 (comment)

Interesting, I'm going to have a look. The test passes on my x86_64-unknown-linux-gnu; I'll try to find what's different in the CI job. The name dist-i586-gnu-i586-i686-musl suggests that it's a 32-bit build - where can I find out more? Is there a way to run the same setup locally?

tgross35 · 2025-07-11T08:36:12Z

You might be able to get away with passing --target ... to ./x since these tests should still be able to run on your host. It looks like it fails testing i686-unknown-linux-musl.

If that doesn't repro it for some reason you can replicate the CI setup pretty much exactly by running the docker tests https://rustc-dev-guide.rust-lang.org/tests/docker.html, with the downside that this takes about as long as CI does.

sebastianpoeplau · 2025-07-11T10:29:20Z

Hmm, the full log of the CI job led me to believe that it's i586-unknown-linux-gnu, but locally the test passes for that target (running ./x.py test tests/debuginfo/embedded-visualizer.rs --target i586-unknown-linux-gnu). Will try with the musl target 👍

I noticed though that my GDB is version 15, whereas the test log shows GDB 12; maybe that's the reason for the discrepancy. In general, the .debug_gdb_scripts section looks correct to me...

tgross35 · 2025-07-11T10:45:44Z

You're right, it's i586. I must have been reading the wrong line.

##[group]Testing stage2 compiletest suite=debuginfo mode=debuginfo (x86_64-unknown-linux-gnu -> i586-unknown-linux-gnu)

I assume there probably isn't any reason we need to keep a very old gdb version if that makes a difference

…ection, r=bjorn3 Preserve the .debug_gdb_scripts section Make sure that compiler and linker don't optimize the section's contents away by adding the global holding the data to `llvm.used`. This eliminates the need for a volatile load in the main shim; since the LLVM codegen backend is the only implementer of the corresponding trait function, remove it entirely. Pretty printers in dylib dependencies are now emitted by the main crate instead of the dylib; apart from matching how rlibs are handled, this approach has the advantage that `omit_gdb_pretty_printer_section` keeps working with dylib dependencies. r? `@bjorn3`

bors · 2025-08-06T09:33:42Z

⌛ Testing commit cc2d4b0 with merge 97bb075...

bors · 2025-08-06T10:51:09Z

💔 Test failed - checks-actions

sebastianpoeplau · 2025-08-06T11:21:00Z

There's a problem with old linkers again: We're emitting the volatile load in the main shim, but pretty printers are now collected per crate, meaning that the load only preserves the main crate's pretty printers. As far as I can see, this affects only a single test (which uses pretty printers from an rlib). Maybe it's okay to disable it, expecting that people generally have more recent linkers than the CI setup?

Instead of collecting pretty printers transitively when building executables/staticlibs/cdylibs, let the debugger find each crate's pretty printers via its .debug_gdb_scripts section. This covers the case where libraries defining custom pretty printers are loaded dynamically.

bjorn3 · 2025-08-06T11:29:56Z

@bors r+

bors · 2025-08-06T11:29:59Z

📌 Commit b4d923c has been approved by bjorn3

It is now in the queue for this repository.

…ection, r=bjorn3 Preserve the .debug_gdb_scripts section Make sure that compiler and linker don't optimize the section's contents away by adding the global holding the data to `llvm.used`. This eliminates the need for a volatile load in the main shim; since the LLVM codegen backend is the only implementer of the corresponding trait function, remove it entirely. Pretty printers in dylib dependencies are now emitted by the main crate instead of the dylib; apart from matching how rlibs are handled, this approach has the advantage that `omit_gdb_pretty_printer_section` keeps working with dylib dependencies. r? `@bjorn3`

bors · 2025-08-06T11:52:27Z

⌛ Testing commit b4d923c with merge d82cad8...

…b-scripts-section, r=bjorn3 Preserve the .debug_gdb_scripts section Make sure that compiler and linker don't optimize the section's contents away by adding the global holding the data to `llvm.used`. This eliminates the need for a volatile load in the main shim; since the LLVM codegen backend is the only implementer of the corresponding trait function, remove it entirely. Pretty printers in dylib dependencies are now emitted by the main crate instead of the dylib; apart from matching how rlibs are handled, this approach has the advantage that `omit_gdb_pretty_printer_section` keeps working with dylib dependencies. r? `@bjorn3`

Zalathar · 2025-08-06T12:10:59Z

Yielding to enclosing rollup:

@bors retry

Rollup of 21 pull requests Successful merges: - #137831 (Tweak auto trait errors) - #138689 (add nvptx_target_feature) - #140267 (implement continue_ok and break_ok for ControlFlow) - #143679 (Preserve the .debug_gdb_scripts section) - #143857 (Port #[macro_export] to the new attribute parsing infrastructure) - #143929 (Mark all deprecation lints in name resolution as deny-by-default and report-in-deps) - #144133 (Stabilize const TypeId::of) - #144369 (Upgrade semicolon_in_expressions_from_macros from warn to deny) - #144473 (Address libunwind.a inconsistency issues in the bootstrap program) - #144498 (Add --print target-spec-json-schema) - #144552 (Rehome 33 `tests/ui/issues/` tests to other subdirectories under `tests/ui/`) - #144659 (bootstrap: refactor mingw dist and fix gnullvm) - #144676 (Add documentation for unstable_feature_bound) - #144794 (Port `#[coroutine]` to the new attribute system) - #144835 (Anonymize binders in tail call sig) - #144836 (Change visibility of Args new function) - #144861 (Stabilize `panic_payload_as_str` feature) - #144910 (Add regression tests for seemingly fixed issues) - #144913 ([rustdoc] Fix wrong `i` tooltip icon) - #144917 (Enforce tail call type is related to body return type in borrowck) - #144924 (compiletest: add hint for when a ui test produces no errors) r? `@ghost` `@rustbot` modify labels: rollup

bors · 2025-08-06T13:02:39Z

⌛ Testing commit b4d923c with merge 8fb40f7...

bors · 2025-08-06T16:15:54Z

☀️ Test successful - checks-actions
Approved by: bjorn3
Pushing 8fb40f7 to master...

github-actions · 2025-08-06T16:19:05Z

What is this?

This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing dc0bae1 (parent) -> 8fb40f7 (this PR)

Test differences

Show 2 test diffs

Stage 2

[run-make] tests/run-make/compressed-debuginfo-zstd: ignore (ignored if LLVM wasn't build with zstd for ELF section compression (we want LLVM/LLD to be built with zstd support)) -> pass (J0)
[debuginfo-gdb] tests/debuginfo/embedded-visualizer.rs: pass -> ignore (ignored when the target environment is musl (linker too old in CI)) (J1)

Job group index

J0: x86_64-gnu-nopt
J1: dist-i586-gnu-i586-i686-musl, test-various

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard 8fb40f798a23adf608182ce5f4eb151fdc8e0da5 --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

dist-apple-various: 3912.5s -> 5491.3s (40.4%)
pr-check-1: 2332.5s -> 1521.3s (-34.8%)
x86_64-rust-for-linux: 3779.0s -> 2547.4s (-32.6%)
pr-check-2: 3358.5s -> 2328.5s (-30.7%)
x86_64-apple-2: 6851.9s -> 4977.4s (-27.4%)
x86_64-gnu-tools: 4683.9s -> 3427.8s (-26.8%)
x86_64-gnu-miri: 5913.9s -> 4640.4s (-21.5%)
test-various: 6037.5s -> 4759.3s (-21.2%)
x86_64-gnu-stable: 9070.6s -> 7240.5s (-20.2%)
dist-x86_64-apple: 13498.6s -> 10920.4s (-19.1%)

How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

rust-timer · 2025-08-06T17:29:02Z

Finished benchmarking commit (8fb40f7): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

Our benchmarks found a performance regression caused by this PR.
This might be an actual regression, but it can also be just noise.

Next Steps:

If the regression was expected or you think it can be justified,
please write a comment with sufficient written justification, and add
@rustbot label: +perf-regression-triaged to it, to mark the regression as triaged.
If you think that you know of a way to resolve the regression, try to create
a new PR with a fix for the regression.
If you do not understand the regression or you think that it is just noise,
you can ask the @rust-lang/wg-compiler-performance working group for help (members of this group
were already notified of this PR).

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	103.7%	[55.2%, 152.2%]	2
Regressions ❌ (secondary)	0.5%	[0.5%, 0.6%]	3
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-1.8%	[-4.6%, -0.0%]	6
All ❌✅ (primary)	103.7%	[55.2%, 152.2%]	2

Max RSS (memory usage)

Results (primary 2.6%, secondary 3.0%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	2.6%	[2.2%, 2.8%]	3
Regressions ❌ (secondary)	3.0%	[3.0%, 3.0%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	2.6%	[2.2%, 2.8%]	3

Cycles

Results (primary 99.0%, secondary 0.9%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	99.0%	[53.9%, 144.0%]	2
Regressions ❌ (secondary)	4.0%	[2.8%, 6.4%]	4
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.2%	[-2.8%, -1.4%]	4
All ❌✅ (primary)	99.0%	[53.9%, 144.0%]	2

Binary size

Results (primary 0.2%, secondary 0.3%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	0.2%	[0.0%, 0.8%]	46
Regressions ❌ (secondary)	0.3%	[0.0%, 1.3%]	86
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.2%	[0.0%, 0.8%]	46

Bootstrap: 463.057s -> 464.179s (0.24%)
Artifact size: 377.38 MiB -> 377.38 MiB (-0.00%)

bjorn3 · 2025-08-06T18:08:11Z

Opened #145014 to temporarily revert this PR.

bjorn3 · 2025-08-06T18:13:18Z

I think the reason for the perf regression is that something is causing codegen units to be codegened again when that previously didn't happen. I see that the debugger_visualizers query is marked as eval_always, but I would expect that to not codegen all codegen units again when the result of the query stays the same.

rustbot assigned bjorn3 Jul 9, 2025

bjorn3 reviewed Jul 9, 2025

View reviewed changes

compiler/rustc_codegen_llvm/src/debuginfo/gdb.rs Outdated Show resolved Hide resolved

sebastianpoeplau force-pushed the preserve-debug-gdb-scripts-section branch 2 times, most recently from 97ac05e to 07de96b Compare July 9, 2025 12:16

bjorn3 reviewed Jul 9, 2025

View reviewed changes

compiler/rustc_codegen_gcc/src/debuginfo.rs Show resolved Hide resolved

bjorn3 reviewed Jul 9, 2025

View reviewed changes

tests/codegen/gdb_debug_script_load.rs Outdated Show resolved Hide resolved

sebastianpoeplau force-pushed the preserve-debug-gdb-scripts-section branch from 07de96b to d54c3ea Compare July 9, 2025 13:20

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 9, 2025

tgross35 mentioned this pull request Jul 10, 2025

Rollup of 8 pull requests #143753

Closed

tgross35 mentioned this pull request Jul 10, 2025

Rollup of 8 pull requests #143755

Closed

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 11, 2025

This comment has been minimized.

Sign in to view

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 6, 2025

sebastianpoeplau force-pushed the preserve-debug-gdb-scripts-section branch from cc2d4b0 to b4d923c Compare August 6, 2025 11:24

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 6, 2025

Zalathar mentioned this pull request Aug 6, 2025

Rollup of 21 pull requests #144995

Closed

bors added the merged-by-bors This PR was explicitly merged by bors. label Aug 6, 2025

bors merged commit 8fb40f7 into rust-lang:master Aug 6, 2025
11 checks passed

rustbot added this to the 1.91.0 milestone Aug 6, 2025

rustbot added the perf-regression Performance regression. label Aug 6, 2025

bjorn3 mentioned this pull request Aug 6, 2025

Revert "Preserve the .debug_gdb_scripts section" #145014

Open

Preserve the .debug_gdb_scripts section #143679

Preserve the .debug_gdb_scripts section #143679

Conversation

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

Uh oh!

Uh oh!

rustbot commented Jul 9, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

bjorn3 commented Jul 9, 2025

Uh oh!

bors commented Jul 9, 2025

Uh oh!

tgross35 commented Jul 11, 2025

Uh oh!

rust-bors bot commented Jul 11, 2025

Uh oh!

rust-bors bot commented Jul 11, 2025

Uh oh!

sebastianpoeplau commented Jul 11, 2025

Uh oh!

tgross35 commented Jul 11, 2025

Uh oh!

sebastianpoeplau commented Jul 11, 2025

Uh oh!

tgross35 commented Jul 11, 2025

Uh oh!

bors commented Aug 6, 2025

Uh oh!

This comment has been minimized.

bors commented Aug 6, 2025

Uh oh!

sebastianpoeplau commented Aug 6, 2025

Uh oh!

bjorn3 commented Aug 6, 2025

Uh oh!

bors commented Aug 6, 2025

Uh oh!

bors commented Aug 6, 2025

Uh oh!

Zalathar commented Aug 6, 2025

Uh oh!

bors commented Aug 6, 2025

Uh oh!

bors commented Aug 6, 2025

Uh oh!

Uh oh!

github-actions bot commented Aug 6, 2025

Test differences

Stage 2

Job duration changes

Uh oh!

rust-timer commented Aug 6, 2025

Overall result: ❌✅ regressions and improvements - please read the text below

Instruction count

Max RSS (memory usage)

Cycles

Binary size

Uh oh!

bjorn3 commented Aug 6, 2025

Uh oh!

bjorn3 commented Aug 6, 2025

Uh oh!

Uh oh!

sebastianpoeplau commented Jul 9, 2025 •

edited

Loading