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.

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

sebastianpoeplau · 2025-07-11T12:02:12Z

Getting closer 😋 I can reproduce the failure in the Docker container via src/ci/docker/run.sh --dev dist-i586-gnu-i586-i686-musl, then ../x test tests/debuginfo/embedded-visualizer.rs --target i586-unknown-linux-gnu inside the container (thanks for the hint!). It seems that the binary just doesn't have a .debug_gdb_scripts section 😳 And even more strangely, the test succeeds with --target i686-unknown-linux-gnu (i.e., just replacing i586 with i686). Maybe LLVM somehow doesn't support llvm.used on i586? 🤔

bjorn3 · 2025-07-11T12:07:35Z

Maybe the linker is just too old in that docker image? SHF_GNU_RETAIN has been added less than 5 years ago.

Edit: Never mind. That wouldn't explain why it works for i686 within the same container.

sebastianpoeplau · 2025-07-11T12:15:27Z

It's still a valid remark:

$ i586-unknown-linux-gnu-ld --version
GNU ld (crosstool-NG UNKNOWN) 2.32
Copyright (C) 2019 Free Software Foundation, Inc.

SHF_GNU_RETAIN was added around 2020; the LLVM patch employing it for llvm.used says:

If a global object is listed in @llvm.used, place it in a unique section with
the SHF_GNU_RETAIN flag. The section is a GC root under ld --gc-sections
with LLD>=13 or GNU ld>=2.36.

Does i686 use a different linker by any chance? For example, if it used the container's /usr/bin/ld, that would be version 2.38.

sebastianpoeplau · 2025-07-11T14:20:19Z

i686 does indeed use a different linker. The contents of the .comment section suggest that i686-unknown-linux-gnu uses the system's GCC 11, whereas i586-unknown-linux-gnu links with GCC 8 from crosstool-ng. The former comes with a linker that supports SHF_GNU_RETAIN, the latter doesn't.

So where does that leave us regarding the test failure on i586? Is it possible to upgrade the crosstool-ng toolchain? Is compatibility with the old ld version required? Can the test simply be disabled for that target?

bjorn3 · 2025-07-11T14:25:06Z

I think just ignoring the test on i586 with a comment that CI uses a too old linker is fine.

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.

rustbot · 2025-07-11T14:47:39Z

Some changes occurred in src/tools/compiletest

cc @jieyouxu

bjorn3 · 2025-07-11T14:50:12Z

@bors r+

bors · 2025-07-11T14:50:16Z

📌 Commit 8be915f has been approved by bjorn3

It is now in the queue for this repository.

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

sebastianpoeplau force-pushed the preserve-debug-gdb-scripts-section branch from d54c3ea to 8be915f Compare July 11, 2025 14:47

rustbot added A-compiletest Area: The compiletest test runner A-testsuite Area: The testsuite used to check the correctness of rustc T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) labels Jul 11, 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-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jul 11, 2025

Preserve the .debug_gdb_scripts section #143679

Are you sure you want to change the base?

Preserve the .debug_gdb_scripts section #143679

Uh oh!

Conversation

sebastianpoeplau commented Jul 9, 2025

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!

sebastianpoeplau commented Jul 11, 2025

Uh oh!

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

Uh oh!

Uh oh!

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

Uh oh!

Uh oh!

sebastianpoeplau commented Jul 11, 2025

Uh oh!

bjorn3 commented Jul 11, 2025

Uh oh!

rustbot commented Jul 11, 2025

Uh oh!

bjorn3 commented Jul 11, 2025

Uh oh!

bors commented Jul 11, 2025

Uh oh!

Uh oh!

bjorn3 commented Jul 11, 2025 •

edited

Loading

sebastianpoeplau commented Jul 11, 2025 •

edited

Loading