These commits modify compiler targets.
(See the Target Tier Policy.)

r? @chenyukang

rustbot has assigned @chenyukang.
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

cc *-windows-gnullvm target maintainers in case you know of any issues with embedding gdb visualizer scripts
@mati865 @thomcc

IIRC this was because it requires GDB with Python support, which was not that common back in the day. Considering that https://github.com/niXman/mingw-builds-binaries now provides Python3 this is probably fine.

I'll test it next week, r? @mati865

@bors try jobs=dist-x86_64-llvm-mingw,dist-x86_64-mingw

☀️ Try build successful (CI)
Build commit: e1f2d44 (e1f2d44674ff1da2152446756fed287873e13d5b, parent: e73c56abd0baf3dbaafbdc3ce6072a416aade867)

How did you test that?

LLD discards this section, so building for windows-gnullvm targets or windows-gnu with LLD as the linker results in binaries without this section.

Then testing with windows-gnu and the default ld.bfd linker, and regular GDB binary there is a warning about missing scripts:

❯ gdb --version
GNU gdb (GDB) 17.1
Copyright (C) 2025 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

❯ gdb -q foo.exe
Reading symbols from foo.exe...
warning: Missing auto-load script at offset 0 in section .debug_gdb_scripts
of file G:\msys64\tmp\foo.exe.
Use `info auto-load python-scripts [REGEXP]' to list them.
(gdb) i auto-load
gdb-scripts:  No auto-load scripts.
local-gdbinit:  Local .gdbinit file was not found.
python-scripts:
Loaded  Script
No      gdb_load_rust_pretty_printers.py
...
(gdb) print x
$1 = alloc::vec::Vec<i32, alloc::alloc::Global> {buf: alloc::raw_vec::RawVec<i32, alloc::alloc::Global> {inner: alloc::raw_vec::RawVecInner<alloc::alloc::Global> {ptr: core::ptr::unique::Unique<u8> {pointer: core::ptr::non_null::NonNull<u8> {pointer: 0xc7960}, _marker: core::marker::PhantomData<u8>}, cap: core::num::niche_types::UsizeNoHighBit (3), alloc: alloc::alloc::Global}, _marker: core::marker::PhantomData<i32>}, len: 3}

It appears to load fine when using rust-gdb which is non-trivial on this target and requires specifying exact path:

❯ rust-gdb +nightly-x86_64-pc-windows-gnu foo.exe
error: the 'rust-gdb.exe' binary, normally provided by the 'rustc' component, is not applicable to the 'nightly-x86_64-pc-windows-gnu' toolchain

❯ /c/Users/Mateusz/.rustup/toolchains/nightly-x86_64-pc-windows-gnu/bin/rust-gdb -q foo.exe
Reading symbols from foo.exe...
(gdb) i auto-load
gdb-scripts:  No auto-load scripts.
local-gdbinit:  Local .gdbinit file was not found.
python-scripts:
Loaded  Script
Yes     gdb_load_rust_pretty_printers.py
        full name: C:\Users\Mateusz\.rustup\toolchains\nightly-x86_64-pc-windows-gnu\lib\rustlib\etc\gdb_load_rust_pretty_printers.py
...
(gdb) print x
$1 = Vec(size=3) = {1, 2, 3}

So, there is a benefit from this change, but only when doing additional setup, otherwise this results in a warning each time you start the debugger.
Based on the outcome this doesn't sound to me like embedding the script, more like referencing it in the auto-load. Is it supposed to work this way?

@rustbot author

Reminder, once the PR becomes ready for a review, use @rustbot ready.

LLD discards this section

Yeah, that's definitely weird. I dont know enough about linkers to know why it's happening. ld worked fine for me as well.

Based on the outcome this doesn't sound to me like embedding the script, more like referencing it in the auto-load. Is it supposed to work this way?

As I understand it, since these are arbitrary python scripts being run automatically, there's a huge security risk. That means all auto-load scripts are opt-in, even when they're embedded. rust-gdb more or less just automatically opts the user in for that session.

The rust-distributed scripts are embedded via a reference to the script file's location, rather than embedding the full script source code (which is what happens via #![debugger_visualizer]). That's somewhat convenient because:

1. You can add the rust-distributed script path to your auto-load safe path via .gdbinit and have them loaded for all gdb debugging sessions (even without rust-gdb)
2. If you do the above, you opt in to rust's visualizers but not any other visualizer embedded in the binary, which is a nice option to have, security-wise.

Without this change, the only way to use the rust visualizers is rust-gdb or manually loading the scripts yourself. Additionally, anything specified by #![debugger_visualizer] is completely discarded at compile time, so if a dependency has a visualizer script, you would need to manually obtain the script and manually load it in at debug-time.

While there is friction even with the change, i dont think it's a huge deal. I havent gotten to look at the debug info survey results, but i'd hazard a guess and say that the population that uses GDB on windows is absolutely minuscule. Anyone that's doing it is jumping through hoops to use gdb anyway, so they'll probably be more tolerant of a few bumps.

@rustbot ready

Yeah, that's definitely weird. I dont know enough about linkers to know why it's happening. ld worked fine for me as well.

I guess this section is not marked as excluded from GC in MinGW/COFF backend, but I haven't tested it.

Thanks for the explanation, I have tested it on Linux and it behaves the same way.

Without this change, the only way to use the rust visualizers is rust-gdb or manually loading the scripts yourself.

FWIW, without this change even using rust-gdb doesn't provide visualizers (at least on Linux), I had to manually load the script. To test Linux binary without this section I had used objcopy -R .debug_gdb_scripts foo foo_no_vis.

@bors r+ rollup

📌 Commit 472b966 has been approved by mati865

It is now in the queue for this repository.

☀️ Test successful - CI
Approved by: mati865
Duration: 3h 41m 15s
Pushing 14196db to main...

Comparing dab8d9d (parent) -> 14196db (this PR)

Test differences

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

Job duration changes

1. aarch64-apple: 2h 48m -> 3h 34m (+27.2%)
2. dist-aarch64-apple: 2h 22m -> 1h 47m (-24.4%)
3. dist-x86_64-apple: 1h 56m -> 1h 39m (-14.4%)
4. dist-aarch64-msvc: 1h 41m -> 1h 49m (+7.9%)
5. dist-loongarch64-linux: 1h 54m -> 1h 46m (-7.0%)
6. dist-aarch64-llvm-mingw: 1h 35m -> 1h 42m (+7.0%)
7. i686-gnu-1: 2h 24m -> 2h 14m (-7.0%)
8. pr-check-1: 33m 9s -> 30m 58s (-6.6%)
9. x86_64-mingw-2: 2h 42m -> 2h 32m (-6.5%)
10. x86_64-mingw-1: 2h 37m -> 2h 47m (+6.4%)

Finished benchmarking commit (14196db): comparison URL.

Overall result: ❌ regressions - no action needed

@rustbot label: -perf-regression

Instruction count

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

Max RSS (memory usage)

Cycles

Binary size

Bootstrap: 489.963s -> 491.114s (0.23%)
Artifact size: 394.27 MiB -> 394.23 MiB (-0.01%)

Could this be the cause of #155277? It's a PR that vaguely matches the symptoms we see and I think it's part of the right nightly range.

Yeah, we will have to revert this PR.