Add the GDB pretty-printers to the Windows Rust installation

[bruno-medeiros]

The pretty printers can be made to work in Windows, as described here: http://stackoverflow.com/questions/33570021/how-to-set-up-gdb-for-debugging-rust-programs-in-windows/33570022#33570022

At a minimum the GDB pretty-printers should be added to the Windows GNU ABI Rust installation, so that they don't have to downloaded separately.

At best, the pretty-printers GDB auto-loading should work as well. I think for that the GDB auto-load info should be added to the debug information of the generated code in Windows.

@michaelwoerister Regarding this comment: #16365 (comment) , what issues did you have trying this out in Windows?

[bombless]

At the end of 2014, you can debug Rust file on gdb with pretty-printer support. So I think someone fixed that problem that bothered @michaelwoerister at that time (for once).
And for some reason the pretty-printer didn't work on Windows around Apirl, 2015.

[michaelwoerister]

Sorry , just discovered this issue now. The problem at the time was that on two out of three Windows systems that I tested things on, GDB would hang indefinitely when trying to load the program.

I'd say there is no harm in adding the python scripts to the Windows installation. About the .debug_gdb_scripts, I would want to test if it doesn't interfere with regular program execution. If it doesn't, we can add it.

[cyplo]

Hi ! Is this still an issue ?

[Mark-Simulacrum]

@michaelwoerister Do you know if this has been fixed?

[michaelwoerister]

I don't really know what the state of GDB on Windows is these days. @brson would know more about what we distribute on which platforms. My statement from before is still true: I have no problem with distributing the python scripts on Windows and someone would need to test if the .debug_gdb_scripts section causes problems. But I also still think that GDB should not be considered a tier 1 tool on Windows.

[Mark-Simulacrum]

Looking at a recent nightly, it seems we do distribute the pretty printing scripts and rust-gdb on windows. We don't insert the debug_gdb_scripts section, though I don't know why:

rust/src/librustc_trans/debuginfo/gdb.rs

Lines 85 to 88 in 80271e8

	!omit_gdb_pretty_printer_section &&
	!ccx.sess().target.target.options.is_like_osx &&
	!ccx.sess().target.target.options.is_like_windows &&
	ccx.sess().opts.debuginfo != NoDebugInfo

.

rust-nightly-x86_64-pc-windows-gnu/rustc/bin/rust-gdb
rust-nightly-x86_64-pc-windows-gnu/rust-docs/share/doc/rust/html/unstable-book/language-features/omit-gdb-pretty-printer-section.html
rust-nightly-x86_64-pc-windows-gnu/rustc/lib/rustlib/etc/gdb_rust_pretty_printing.py
rust-nightly-x86_64-pc-windows-gnu/rustc/lib/rustlib/etc/gdb_load_rust_pretty_printers.py

[michaelwoerister]

We don't insert the debug_gdb_scripts section, though I don't know why.

Because it made GDB on Windows hang or crash at the time this code was written.

[mickaelistria]

Is there any progress on this topic?

[mickaelistria]

someone would need to test if the .debug_gdb_scripts section causes problems

Did anyone re-try it with latest versions of everything since this statement was made 15 months ago?

But I also still think that GDB should not be considered a tier 1 tool on Windows.

What do you suggest instead? Is there any other debugger for Windows well integrated in the Rust toolchain?

cc @Boereck

[Boereck]

I was searching how Rust debugging can be done in VS Code and found the C++ extension supports debugging via MSVC. The C++ extension uses the debug adapter protocol. Looking at the source code and package.json file, it looks like the DAP server is downloaded here. But reading the license.txt file inside the zip file it is unclear to me if these binaries are allowed to be used by other tools than the VS Code extension and Visual Studio itself.
So it doesn't seem clear if there is a good alternative to GDB on Windows for other tools than VS Code and Visual Studio.

[mickaelistria]

Thanks for checking @Boereck
I'd rather avoid using msvc, vsdgb and so on. Some former experiments with Microsoft debuggers have highlighted they implement vendor locking https://twitter.com/mickaelistria/status/950727748116533250/photo/1 to lock users to their IDEs. It's a path we should avoid for an open-source project, unless things changes and MS debuggers are now OSS too.

[Boereck]

At least I haven't had a problem with a hanging MinGW (GDB version 8.1 and 8.2). Maybe it is time to check if the hanging is still occurring with recent GCC builds.
I've written a powershell script and a batch file analogous to the rust-gdb script you are free to adopt.

Powershell:

# Exit if anything fails
$ErrorActionPreference = "Stop"

# Find out where the pretty printer Python module is
$RUSTC_SYSROOT = rustc --print=sysroot
$GDB_PYTHON_MODULE_DIRECTORY = "$RUSTC_SYSROOT\lib\rustlib\etc" #-replace '\\','/'

if ($LASTEXITCODE -ne 0) {
    throw "rustc exited with $LASTEXITCODE"
}

# Run GDB with the additional arguments that load the pretty printers
# Set the environment variable `RUST_GDB` to overwrite the call to a
# different/specific command (defaults to `gdb`).
if (Test-Path env:RUST_GDB) {
    $RUST_GDB = $env:RUST_GDB
} else {
    $RUST_GDB = "gdb"
}

$PYTHONPATH="$env:PYTHONPATH;$GDB_PYTHON_MODULE_DIRECTORY"
& "$RUST_GDB" --directory="$GDB_PYTHON_MODULE_DIRECTORY" -iex "add-auto-load-safe-path $GDB_PYTHON_MODULE_DIRECTORY" $args

Batch:

@echo off

REM  Find out where the pretty printer Python module is

for /f %%s in ('rustc --print=sysroot') do SET RUSTC_SYSROOT=%%s
REM appearently %errorlevel% does not get set in code above, so let's check for RUSTC_SYSROOT
if not defined RUSTC_SYSROOT (  exit /b 1 )
SET GDB_PYTHON_MODULE_DIRECTORY=%RUSTC_SYSROOT%\lib\rustlib\etc

REM  Run GDB with the additional arguments that load the pretty printers
REM  Set the environment variable `RUST_GDB` to overwrite the call to a
REM  different/specific command (defaults to `gdb`).
if not defined RUST_GDB ( SET RUST_GDB=gdb )

if not defined PYTHONPATH ( 
	SET PYTHONPATH=%GDB_PYTHON_MODULE_DIRECTORY%
) else (
	SET PYTHONPATH=%PYTHONPATH%;%GDB_PYTHON_MODULE_DIRECTORY%
)

%RUST_GDB% --directory="%GDB_PYTHON_MODULE_DIRECTORY%" -iex "add-auto-load-safe-path %GDB_PYTHON_MODULE_DIRECTORY%" %*

Edit: Deleted duplicate functionality from batch file.

[norru]

#54615

[tromey]

Distributing these scripts seems to be pretty easy to do, with a tweak in https://github.com/rust-lang/rust/blob/master/src/bootstrap/dist.rs#L591-L614

[Boereck]

Is there any update on this? Shipping a Windows script for rust-gdb would be a much better out-of-the-box experience, especially when using tools relying on it being present.

[hydra]

See also:

rust-lang/rustup#2843
rust-lang/rustup#2838

[jgardona]

Yep, heppening todat also.