Windows Debug hello World -> Unable to launch Rust Project from selection

[Coalado]

I installed rust, eclipse, created a new cargo project and tried to launch it.

Eclipse opened the settings panel complaining: "install missing rls component in rustup"
I installed rustup component add rls-preview rust-analysis rust-src and the message was gone. It would have been nice to get a better help than "install missing rls component in rustup"

Running the application worked fine now, but debugging gave me:

I should mention, that I'm a rust newcomer without hardly any C/C++ background, but I suppose this actually should run "out of the box"?

[Boereck]

The timing is funny, PR #148 was just merged, which probably takes care of your problem. Note that you will probably face further problems on Windows, since the gdb-rust tool is just a shim in the Rust "windows-gnu" targets writing an error message (see this ticket ). In the debug config you have to specify the absolute path to your gdb directly instead. And you have to add a few lines to your "gdbinit" ( or ".gdbinit") file, which you also have to configure as an absolute path. Here is the needed content of the "gdbinit" file:

python
print "---- Loading Rust pretty-printers ----"

sys.path.insert(0, "C:/<rust_install>/lib/rustlib/etc")
import gdb_rust_pretty_printing
gdb_rust_pretty_printing.register_printers(gdb)

end

The rust install directory is usually under your user's home, so something like this: <user_dir>/.rustup/toolchains/stable-x86_64-pc-windows-gnu.
There might already be pretty printers configured, in this case just copy the part between python and end in the existing block of your "gdbinit" file.

I hope this helps.

[Boereck]

Note: As a workaround you can right now specify the absolute path to the executable to be debugged in the debug configuration. This way you don't have to wait for PR #148 to land in a Corrosion release.

[mickaelistria]

Snapshots were already built including patches from @Boereck (thanks to him by the way!).
So you can also install the snapshots from http://download.eclipse.org/corrosion/snapshots/ (with Help > Install New Software), this will update Corrosion to a version that should fix it.
Please report whether the fix is valid for you or not. If it is, we'll close the issue; if not, please continue give some more details to troubleshoot this bug.

[mickaelistria]

@Boereck Once you are convinced this issue is fixed, we can decide to trigger a release ASAP. I think this issue is critical enough to be worth it.

[Boereck]

I will test the snapshot build later today to be sure the fix is working not only in my dev environment and give feedback.

[Coalado]

The debug action now does ..nothing.

[Boereck]

I found two more issues (one of which I introduced myself) which I addressed in #152, but the missing gdb-rust still prevents right-click "Debug As > Rust Project" from working on Windows. But creating a debug configuration should be a smoother experience on Windows.

[Boereck]

I've tested the current snapshot and the program path issue seems to be resolved. I didn't observe path related errors on Windows and Linux. However, the gdb issue is still there.

I have been thinking about this issue a bit more. It is unfortunate that rust does not ship a working version of the gdb-rust tool. So what are the options we have to make the "Debug As" functionality work on Windows?

I think what we could do is taking the GDB configuration from the C++ preferences by default on Windows. This makes the "Debug As" functionality work as long as the preferences are configured correctly. Maybe we can add some explanation for Windows users to configure GDB in the preferences in the README.md file.

Regarding the pretty printers:
I feel uncomfortable messing around with the gdbinit file or even providing one with Corrosion to reference. We could try to find out the currently used toolchain, look up the python scripts and issue python execfile(...) calls to gdb on startup. Alternatively we could again add some documentation on how to add the pretty printers to the gdbinit file. My personal opinion would be to go with the second approach, because it limits the amount of workarounds we have to maintain. We should also document that the pretty printers may hang gdb, which is the whole reason why there is no functional gdb-rust shipped with the Windows GNU toolchain.

I consider all this a workaround until gdb-rust is available. But since the issue is open since 2015 and there is no update for over one year, I think it is safe to assume we will live with the current situation for some time to come. As soon as a rust stable version ships with gdb-rust, the workarounds should be removed.

[mickaelistria]

@Boereck the very best thing would be obviously to get it fixed upstream. It seems like the first thing would be to just try the suggested change against latest versions on Windows. It could be a bug in another component that's fixed now. Do you think you'd be able to try this?
@akurtakov Do you think we can find someone at Red Hat who could have a look at the rust-gdb issue rust-lang/rust#29658 ?

[Boereck]

@mickaelistria I had a look and realized gdb-rust is actually a bash script. I guess this makes it even more difficult to ship it with the Windows version. I always assumed it was a Rust program. The logic however is extremely simple. I think it would be feasible to re-implement the tiny logic in Java. So far I haven't had problems with GDB (8.1.0) installed via scoop on a recent Windows 10 using the pretty printing scripts. You are right, we should investigate if there are plans to fix this issue in the Rust project (the preferable outcome). I don't have the resources though to test several GDB distributions on several Windows versions.

[mickaelistria]

I think it would be feasible to re-implement the tiny logic in Java.

Or in powershell upstream?

[Boereck]

I've tried to create a powershell script with the same logic (see below), but it seems MinGW has a bug when passing the add-auto-load-safe-path command. gdb is always complaining that the given directory does not exist ("No such file or directory"), no matter if I use forward or backward slashes in the path. Or there is a different problem that I don't see. Maybe someone else can try this. If it is actually a bug in MinGW we also cannot pull the trick in Java 😔.
Interestingly, when entering the command in the gdb console when the program is started, everything works fine.

# 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

EDIT: Script did contain command used for debugging

[anb0s]

After updating Corrosion today it looks different:

.cargo\rust-gdb.exe just prints at command line:
error: toolchain 'nightly-x86_64-pc-windows-gnu' does not have the binary rust-gdb.exe``

@Boereck: so the issue is that rust-gdb for windows is a .sh script and we need an real executable shipped with rust by rustup?

Anyway: I will try the workarounds with .gdbinit and MinGW GDB 8.2 (from MSYS2)...

[mickaelistria]

so the issue is that rust-gdb for windows is a .sh script and we need an real executable shipped with rust by rustup?

If rust-gdb ships a working .sh script for windows, then we don't really need an executable, we just need the RustDebugTabGroup/RustDebugDelegate to replace the debug command that will be used by invocation of the script.
@akurtakov Does IGDBLaunchConfigurationConstants.ATTR_DEBUG_NAME allow the property to be a debug command that's not an executable (like invoking a script) ?

[Boereck]

@anb0s This behavior is expected right now, since we haven't fixed the second part of the problem. You can still create a run config, directly referencing the GDB on your system and add the lines I stated above to your gdbinit file.

Let me give a bit of background: Rust on Linux comes with the shell script rust-gdb this script does start gdb with some parameters that make gdb load the rust pretty printer scripts. On windows we have two problems:

1. The Windows GNU toolchain of rust does not ship an equivalent rust-gdb script. There is a rust-gdb.exe as part of the toolchain, but all it does is print out an error message.
2. I tried writing a powershell version (see this comment) of the the rust-gdb script to test if we could provide a solution upstream. Unfortunately it seems that MinGW's gdb (at least in version 8.1) does not handle the "execute command" parameter correctly. It looks an awful lot like this MinGW bug, even though this was supposedly fixed in 2016. I will try a newer version of MinGW later.

@mickaelistria I've tried to run a poweshell script using the Java ProcessBuilder (not sure if this is used under the hood) and it does not work directly. You have to call powershell with the script as the parameter. Traditional batch scripts (bat/cmd files) seem to work however.

[Boereck]

So... the MinGW GCC version 8.2 provided via MSYS2 does not have the bug the MinGW 8.1 I installed via scoop. So we have a path forward. We can either

• Call GDB directly on Windows and pass the parameters needed on our own
• Or we try to get the Rust project to adopt a Windows script analogous to the shell script on Linux

[mickaelistria]

@Boereck Good news! Thanks a lot for facing all those challenges!
First thing first, as you're the one who's actively caring about the Windows state, it's up to you to decide. My further comment is only a suggestion, but if you disagree, then as the one who does the stuff, you deserve to get the final word here ;)

I suggest that we first try to put the script in Rust and see how likely it is to happen. If it can be merged upstream then good, we don't have anything to change in Corrosion, and we've made Rust better by the way.
If we receive bad signals about it, we can workaround it by calling GDB with parameters in RLS.
What do you think about it?

[Boereck]

@mickaelistria Yep, I think you are right. I proposed Windows version scripts on the issue and requested a re-evaluation on hanging GDB on Windows. I didn't have any of these problems so far. But I only tested on my machine which is only one version of Windows and only one Intel processor (not tested on AMD processors and other processor generations). Let's see what the Rust folks will say.

By the way: I tried running the batch version of the script from Java and there you just have to specify the script file name (e.g. rust-gdb.cmd). On the command line you can leave out the ".cmd", but when calling from Java the extension cannot be omitted. So either way we do have to do some adjustment to the way things are done today.

[anb0s]

I've tried the workarounds with no luck.

MinGW GDB is usable from cmd and MSYS2 shell:

C:\WINDOWS\system32>where gdb
C:\msys64\mingw64\bin\gdb.exe

C:\WINDOWS\system32>gdb --version
GNU gdb (GDB) 8.2
Copyright (C) 2018 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.

Select it in debug config:

Shows error:

I've adapted .gdbinit like described above, but have no idea if it used at all, because of version error...

[anb0s]

See #138: GDB 8.2 is may be the problem here?

[anb0s]

OK, now it works with MinGW GDB 8.2 if i create other debug config like described in #138 under "C/C++ Application" and full path to executable

with .gdbinit for rust pretty printers --> it stops at breakpoint and shows the Variables :)

So there is something different in debug config under "Rust" for launching gdb with working dir or exe path...

[norru]

That's the same workaround I found, except for the pretty printing (which I haven't got to look at yet).

[norru]

Besides: rust-lang/rust#54615

[Boereck]

@anb0s This is strange! The Rust debug configuration actually uses the CDT mechanisms under the hood to start gdb. This message should only be shown if GDB was not found or GDB printed a very unusual version string. I will try to contribute a change that logs the exact error message, so you can provide more detailed information.

[norru]

@Boereck the Version output of GDB 8.2 is less detailed compared to GDB 8.1, if it helps. See #138

[norru]

This ticket and #138 should be merged, I think...

[anb0s]

@Boereck Yes it's strange. I've just tried it again and shows now the error log:

org.eclipse.cdt.dsf.gdb
Error
Sun Oct 21 21:18:31 CEST 2018
Could not determine GDB version using command: C:\msys64\mingw64\bin\gdb.exe --version

java.lang.Exception: Fatal Python error: _Py_HashRandomization_Init: failed to get random numbers to initialize Python


	at org.eclipse.cdt.dsf.gdb.launching.GdbLaunch.getGDBVersion(GdbLaunch.java:562)
	at org.eclipse.cdt.dsf.gdb.launching.GdbLaunchDelegate.launchDebugSession(GdbLaunchDelegate.java:143)
	at org.eclipse.cdt.dsf.gdb.launching.GdbLaunchDelegate.launchDebugger(GdbLaunchDelegate.java:102)
	at org.eclipse.cdt.dsf.gdb.launching.GdbLaunchDelegate.launch(GdbLaunchDelegate.java:91)
	at org.eclipse.corrosion.debug.RustDebugDelegate.launch(RustDebugDelegate.java:107)
	at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:859)
	at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:717)
	at org.eclipse.debug.internal.ui.DebugUIPlugin.buildAndLaunch(DebugUIPlugin.java:1039)
	at org.eclipse.debug.internal.ui.DebugUIPlugin$8.run(DebugUIPlugin.java:1256)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:60)

No idea why Python shows problem during launch of the GDB executable... The same gdb.exe is working with "C/C++ Application" debug config!

[Boereck]

@anb0s Thanks for the quick feedback! This is at least an error we can try to track down. The error is coming from the stderr of GDB and Python is used by GDB for the pretty printers. Still strange, but at least a lead.

[anb0s]

@Coalado @Boereck : see #138 i think it's fixed now, i can work with MinGW 64 GDB and python pretty printers are working out of the box now. Just the path to gdb.exe must be used...

[mickaelistria]

Thanks for the feedback. Feel free to open new tickets for remaing or new glitches