"process launch failed: unknown error" when trying to run Rust program via LLDB - windows

I am unable to launch Rust binaries with LLDB on Windows 10:
> cat test.rs
fn main() {
println!("hello");
}
> rustc --version --verbose
rustc 1.25.0 (84203cac6 2018-03-25)
binary: rustc
commit-hash: 84203cac67e65ca8640b8392348411098c856985
commit-date: 2018-03-25
host: x86_64-pc-windows-msvc
release: 1.25.0
LLVM version: 6.0
> rustc -g test.rs
> .\test.exe
hello
> lldb --version
lldb version 6.0.0 (https://github.com/llvm-mirror/lldb.git revision 38001b27c9f319a3112271ca44fa0e1912583570)
clang revision b3bac44cb354b63214b16fab24b5c0ffd392ec02
llvm revision bbbe81ad6ad6db7ccb332df1f1932a5589a7eeca
> lldb test.exe
(lldb) target create "test.exe"
Current executable set to 'test.exe' (x86_64).
(lldb) process launch
error: process launch failed: unknown error
LLDB works fine for other executables on my system, for example:
> lldb C:\Windows\system32\cmd.exe
(lldb) target create "C:\\Windows\\system32\\cmd.exe"
Current executable set to 'C:\Windows\system32\cmd.exe' (i686).
(lldb) process launch
Process 15944 launching
(lldb) Process 15944 launched: 'C:\Windows\system32\cmd.exe' (i686)
LLDB and Rust are both fresh installs.
Is there a way to get more information from LLDB about why it isn't working?

I do not believe you can use LLDB to debug a 64-bit Rust program on Windows.
The LLDB home page states:
Windows local user-space debugging for i386 (*)
(*) Support for Windows is under active development. Basic
functionality is expected to work, with functionality improving
rapidly.
And the LLDB extension for Visual Studio Code states (emphasis mine):
At the moment, Windows port of LLDB is known to work reliably only
with 32-bit binaries and DWARF debug info:
LLDB's support of MSVC .PDB debug info format is incomplete. Only DWARF debug info works reliably.
The 64-bit LLDB is very unstable, so I cannot recommend using it. Unfortunately, 32-bit debuggers are limited to debugging 32-bit
processes only.
In practice, the above means that for C++ programs, you'll need to
compile with i686 MinGW toolchain (not MSVC!). For Rust you'll need to
use i686-pc-windows-gnu.
Thus, at this point in time, I would not recommend attempting to use LLDB. Since you have installed the MSVC toolchain, I advise you to investigate installing something native, such as WinDbg:

Related

Can't link hello_world program on Windows: /usr/bin/link: extra operand

I installed Rust on a Windows 10 machine with rustup-init.exe - the method recommended in the Rust Book. The installer told me that Rust needs C-runtime of VS2013 or newer. I have VS2017 installed, I assumed Rust doesn't support VS2017 yet and so agreed to install C-runtime. Installation finished successfully.
main.rs:
fn main() {
println!("Hello, world!");
}
Compiling:
> rustc main.rs
error: linking with `link.exe` failed: exit code: 1
|
= note: "link.exe" "/NOLOGO" "/NXCOMPAT" "/LIBPATH:C:\\Users\\***\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib" "main.0.o" "/OUT:main.exe" "/OPT:REF,NOICF" "/DEBUG" "/LIBPATH:C:\\Users\\***\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib" "C:\\Users\\***\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libstd-0a78323911070f99.rlib" "C:\\Users\\***\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\librand-c279a51d66700350.rlib" "C:\\Users\\***\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libcollections-d7bf31a4ca1ea637.rlib" "C:\\Users\\***\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libstd_unicode-d367c3ba0db49600.rlib" "C:\\Users\\***\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libpanic_unwind-2d4bf02140c11dcb.rlib" "C:\\Users\\***\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libunwind-add7a84d7e82d084.rlib" "C:\\Users\\***\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\liblibc-84688accbc86d6b7.rlib" "C:\\Users\\***\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\liballoc-fe2e68b21f0bdd7a.rlib" "C:\\Users\\***\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\liballoc_system-7fc0381594c93f56.rlib" "C:\\Users\\***\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libcore-ea9d77e7c23fe65c.rlib" "C:\\Users\\***\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libcompiler_builtins-91b619d34dd1f5aa.rlib" "advapi32.lib" "ws2_32.lib" "userenv.lib" "shell32.lib" "msvcrt.lib"
= note: /usr/bin/link: extra operand '/LIBPATH:C:\\Users\\***\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib'
Try '/usr/bin/link --help' for more information.
error: aborting due to previous error
link.exe LIBPATH arg is specified twice.
What's going on?
> rustc --version
rustc 1.17.0 (56124baa9 2017-04-24)
As the rustup documentation says:
As mentioned on the Rust download page, there are two ABIs in use on Windows: the native (MSVC) ABI used by Visual Studio, and the GNU ABI used by the GCC toolchain. Which version of Rust you need depends largely on what C/C++ libraries you want to interoperate with: for interop with software produced by Visual Studio use the MSVC build of Rust; for interop with GNU software built using the MinGW/MSYS2 toolchain use the GNU build.
You have installed the MSVC toolchain. However, you are running the the compiler in a command shell where link.exe does not point to the MSVC linker, but instead to a GNU toolchain — MSVC does not call its linker /usr/bin/link or use options like --help!
You should configure your shell so the MSVC linker is foremost in the PATH or switch to the GNU ABI if that's your goal.
Compare the help output of the two:
$ link --help
Usage: link FILE1 FILE2
or: link OPTION
Call the link function to create a link named FILE2 to an existing FILE1.
--help display this help and exit
--version output version information and exit
GNU coreutils online help: <http://www.gnu.org/software/coreutils/>
Full documentation at: <http://www.gnu.org/software/coreutils/link>
or available locally via: info '(coreutils) link invocation'
> link /help
Microsoft (R) Incremental Linker Version 14.10.25017.0
Copyright (C) Microsoft Corporation. All rights reserved.
For help on Linker, type `link /link' or `link'
For help on Library Manager, type `link /lib' or `lib'
For help on Dumper, type `link /dump' or `dumpbin'
For help on Editor, type `link /edit' or `editbin'
For help on CvtCIL, type `link /cvtcil'
I assumed Rust doesn't support VS2017 yet
It supports VS2017 just fine; as described in the 1.17 release notes, the problem is that it cannot automatically find the MSVC installation due to changes in where MSVC installs. Running the Rust compiler from inside a shell that has the proper environment works fine.

Unable to run Qt debugger on Mac OSX

Trying to debug an application written in Qt on mac (10.6.8). Qt 4.8.6, QtCreator 3.2.0, I set up the debugger System GDB at /usr/bin/gdb and compiler gcc-4.2
I want to debug the code...
I get in the application output window
Debugging starts
Debugging has failed
Debugging has finished
(and no breakpoints were hit, nothing has started in code)
I opened the debug log window, and the only suspicious things I saw were
....
111^error,msg="Undefined command: \"python\". Try \"help\*.*
NOTE: ENGINE SETUP FAILED
State Changed From EngineSetupRequested(1) to EngineSetupFailed(2)
HANDLE RUNCONTROL FINISHED
.....
On the left, some of the commands had
109-interpreter-exec console "python sys.path.insert(1, "/Volumes/QtCreator/..."
110-interpreter-exec console "python sys.path.append("/usr/bin/data-directory/ python)"
111-interpreter-exec console "python from gdbbridge import *"
I checked that python is installed... i can type python from anywhere and get its command prompt so it is on system path...
I read something about having to sign a fsf debugger but the one I am using is not a fsf debugger ?
What can I do to debug my apps in macx ?
Edit: Tried gdb from command line, with the app as argument
GNU gdb 6.3.50-20050815 (Apple version gdb-1518) (Sat Feb 12 02:52:12 UTC 2011)
...
This GDB was configured as "x86_64-apple-darwin"...
warning: Unable to read symbols for QtSvg.framework/Versions/4/QtSvg (file not found).
warning: Unable to read symbols from "QtSvg" (not yet mapped into memory).
warning: Unable to read symbols for QtGui.framework/Versions/4/QtGui (file not found).
warning: Unable to read symbols from "QtGui" (not yet mapped into memory).
warning: Unable to read symbols for QtCore.framework/Versions/4/QtCore (file not found).
warning: Unable to read symbols from "QtCore" (not yet mapped into memory).
warning: Unable to read symbols for QtNetwork.framework/Versions/4/QtNetwork (file not found).
warning: Unable to read symbols from "QtNetwork" (not yet mapped into memory).
Reading symbols for shared libraries .
... some warnings that .o is more recent than .dylib in dependent libs... but that I don't have to step into so I don't care...
...
warning: Could not find object file "/usr/llvm-gcc-4.2/bin/../lib/gcc/i686-apple-darwin11/4.2.1/x86_64/crt3.o" - no debug information available for "darwin-crt3.c".
.... done
So I type run
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000
0x00007fff83872c00 in strlen ()
I don't know where that is (I do but really can't see it) or if it is an actual string pointer or something else...
I don't know where the breakpoints would be, the entire source is very long and contains lots and lots of files so I really don't know how I can do it with gdb from command line...
But it seems that it did get started, without complains about python ?
The warnings at start - could that mean that there is still hope, that it is possible to somehow configure gdb to run with Qt if it learns about its libraries ?
By the way... searching for the missing libraries...
QT 4.8.4 debug libraries not found on Mac OSX
I have tried to replace my debugger (in Qt) using lldb and qmake - in both cases I got an error "Unable to create a debugger engine of the type 'No engine'"
Edit: Another suggestion I read about is to recompile Qt Creator Binaries to add debug symbols... I hope that is not what I have to do because
"Note: With Qt Creator 3.2 we drop support for OS X 10.6 (Snow Leopard). The technical reason for this is that Apple does not support any kind of C++11 on that OS version. Of course that does not affect on which platforms you can run your Qt applications on. But it is not possible to run the Qt Creator 3.2 binaries on 10.6, and it also is not possible to compile Qt Creator 3.2 on 10.6 with the tool chains provided by Apple." (from release notes)
Update: I was able to find the cause of the error above (the KERN_INVALID_ADDRESS) by placing a zillion qDebug() statements... Though that was not what I am trying to accomplish, one error out of many.
I still have lots of errors... Attaching a debugger would be wonderful. I have listed the required libs for the program - they seem to exist. Not sure if they are "debug" or "release" libraries. .... But I am not trying to step through the Qt sources, so why would it matter if I have debug symbols for them ? And if they were "release" type libs, then my whole program, build in "debug", would not execute or even fail to build ? Since I am building my code in "Debug" mode and it executes, the libraries must be correct, right ?
So confusing...
QtCreator 3.2 (and a few versions before that) requires a GDB that has Python scripting enabled (or LLDB, or CDB on Windows). On Mac, Apple's GDB doesn't have Python scripting, and therefore cannot be use with Qt Creator. FSF GDB works for some projects on Mac, but in general LLDB is preferable there.
Your "GNU gdb 6.3.50-20050815 (Apple version gdb-1518)" is such an non-Python-enabled Apple build.

gdb debugging in Terminal OS X (10.8.5) with zsh

For my studies I have to run a binary unix-program bomb with gdb.
Some time ago I followed the steps on http://jakoblaegdsmand.com/blog/2013/04/how-to-get-an-awesome-looking-terminal-on-mac-os-x/ and made some changes to my terminal-setup.
To runbomb with gdb I typed:
-> bomb207 gdb bomb
zsh: correct 'gdb' to 'gdv' [nyae]? n
zsh: command not found: gdb
When I type 'man gdb' zsh answers 'No manual entry for gdb'
How can I change my terminal-setup to support gdb?
ps.
I already installed the command line tools for os x with x code and I didn't had any problems until now...
bomb207 is the current directory and the location of bomb.
It appears that Apple (who have been switching from gcc to clang for some time) stopped including gdb in 10.8. Even in the CommandLine tools.
The clang debugger is lldb. It is similar in use to gdb, and I'm not finding it unduly difficult to switch. Aside from explaining to my finger that they shouldn't type gdb
for the debugger anymore: my fingers don't like change.
Yes, you can still type gcc to compile things, but look:
$ gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin12.5.0
Thread model: posix
on 10.15.6+ you can simply install gdb using homebrew
brew install gdb
You need to install GNU Debugger, or GDB. Try installing the full XCode package?
GDB works fine on my Mac, but then I've got full XCode installed.
Failing that, just for my peace of mind, type 'where gdb' and tell me what it prints out?
On my Mac it's in '/usr/bin/gdb', and on my linux boxes it's in '/usr/bin/gdb' and '/usr/bin/X11/gdb'.

gdb claims it doesn't know how to run

I'm using Xcode 3.2.3 on Mac OS X 10.6.6 on a Mac Pro to build revision 5fd480ef577f of GrowlTunes from the growl-development repository.
With a clean build from a virgin checkout, this is what I get:
% gdb build/Debug/GrowlTunes.app/Contents/MacOS/GrowlTunes
GNU gdb 6.3.50-20050815 (Apple version gdb-1469) (Wed May 5 04:41:34 UTC 2010)
[blah blah blah]
This GDB was configured as "--host=x86_64-apple-darwin --target=powerpc-apple-darwin"...Reading symbols for shared libraries ......... done
(gdb) run
Starting program: /Volumes/RAM Disk/growl-development/Extras/GrowlTunes/build/Debug/GrowlTunes.app/Contents/MacOS/GrowlTunes
Don't know how to run. Try "help target".
When I try it in Xcode, it apparently does some internal test that fails, because it doesn't even list GDB as an option. Since there are no other debuggers (in this version of Xcode) for Cocoa applications, the pop-up menus related to debugging in the target Info window are empty, and attempting to run the app does nothing—the Run button switches back to being the Run button immediately.
The target is built for 32-bit PowerPC and 64-bit Intel:
% file build/Debug/GrowlTunes.app/Contents/MacOS/GrowlTunes
build/Debug/GrowlTunes.app/Contents/MacOS/GrowlTunes: Mach-O universal binary with 2 architectures
build/Debug/GrowlTunes.app/Contents/MacOS/GrowlTunes (for architecture ppc7400): Mach-O executable ppc
build/Debug/GrowlTunes.app/Contents/MacOS/GrowlTunes (for architecture x86_64): Mach-O 64-bit executable x86_64
I can run it directly, either from the terminal or from Finder, but that doesn't help me step-by-step debug.
This isn't a cross compilation scenario; I mean to run the 64-bit Intel architecture, which is my machine's native architecture, not the PowerPC architecture.
I'm guessing this is some build misconfiguration somewhere in the project, but I've no clue what or where. Any suggestions?
Workaround from a contact of mine:
gdb -arch x86_64 build/Debug/GrowlTunes.app/Contents/MacOS/GrowlTunes
I'd still appreciate a solution that would enable me to run/debug the app in Xcode.
Switching the order of the architectures in the relevant build setting fixed the problem both in gdb and in Xcode. This is a lame solution, and I'd still welcome a better one, but at least it works.
At gdb prompt, try 'set arch x86_64' or 'set arch i386:x86-64' (without quotes of course; I am a total newbie with gdb, I am lurking for solutions for other problems)

Why do I get missing DLL errors debugging my Fortran code using GDB on Windows 7 64-bit (using Eclipse/Photran/Cygwin)?

My setup is as follows:
OS: Windows 7 Home Premium 64-bit
Eclipse: Helios 3.6.1 64-bit with CDT
and Photran
Java SE Runtime
Environment: 1.6.0_21
Java Hotspot: 64-bit Server VM
(build 17.0-b17, mixed mode)
Cygwin 1.7.2 (32-bit)
My initial test Fortran application simply prints 'Hello World!' and exits.
The code builds and runs fine, albeit with the following 2 Warnings in the Problems tab in Eclipse
Description Resource Path Location Type
Error launching external scanner info generator (gcc -E -P -v -dD C:/Users/Joe/workspace/.metadata/.plugins/org.eclipse.cdt.make.core/specs.c) HelloFortran Unknown C/C++ Problem
Error launching external scanner info generator (gcc -E -P -v -dD C:/Users/Joe/workspace/.metadata/.plugins/org.eclipse.cdt.make.core/specs.c) HelloFortran Unknown C/C++ Problem
The problem comes when trying to debug the app as a Local Fortran Application which results in this error:
cygwin warning:
MS-DOS style path detected: C:\Users\Joe\workspace\HelloFortran
Preferred POSIX equivalent is: /cygdrive/c/Users/Joe/workspace/HelloFortran
.gdbinit: No such file or directory.
CYGWIN environment variable option "nodosfilewarning" turns off this warning.
Consult the user's guide for more details about POSIX paths:
http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
auto-solib-add on
Undefined command: "auto-solib-add". Try "help".
Error: dll starting at 0x76ba0000 not found.
Error: dll starting at 0x75230000 not found.
Error: dll starting at 0x76ba0000 not found.
Error: dll starting at 0x76aa0000 not found.
[New thread 7060.0x10dc]
[New thread 7060.0x16c0]
I'm guessing the entry points aren't found because it's expecting 32-/64-bit DLL and getting the other type (correct me if I'm wrong). The GDB version is as follows:
GNU gdb 6.8.20080328 (cygwin-special)
GDB configured as "i686-pc-cygwin"
Running GDB from the command-line gives:
[New thread 5768.0x15a0]
Error: dll starting at 0x76ba0000 not found.
Error: dll starting at 0x75230000 not found.
Error: dll starting at 0x76ba0000 not found.
Error: dll starting at 0x76aa0000 not found.
[New thread 5768.0x46c]
hellofortran () at ../HelloFortran.f90:1
1 program HelloFortran
Current language: auto; currently fortran
If I'm reading that correctly the application does run in GDB and I am able to step through it, but what are the missing DLL errors about?
Dependency Walker gives the following errors for my HelloFortran.exe
Error: Modules with different CPU types were found.
Warning: At least one delay-load dependency module was not found.
Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module.
The missing DLLs seem to be IESHIMS.DLL (2) which from my quick research doesn't seem to be a big issue but I don't see any reason my application would need to reference this DLL so I don't think this is leading to the errors in GDB.
All of the modules have a CPU type of x64 except for:
CYGGCC_S-1.DLL
CYGGFORTRAN-3.DLL
CYGWIN1.DLL
HELLOFORTRAN.EXE
which have a CPU type of x86
I'm concerned the missing DLL errors could harm my ability to debug my program properly (although the program will eventually run on a Unix-based HPC so I shouldn't run into these issues there since all those DLLs seem to be to do with Cygwin).
My questions:
Why do I get missing DLL errors? (Would switching to 32-bit versions of Eclipse/JVM etc fix this?)
Am I
okay to continue, or should I solve
the missing DLL errors (and if so,
how)?
Edit: My test program is as follows:
program HelloFortran
! Force variable declaration
implicit none
! Print 'Hello World!' to the main output
write (*,*) 'Hello World!'
! End program
end program HelloFortran
Why do I get missing DLL errors?
When Win/x64 sends a DebugEvent to 32-bit process about a 64-bit DLL that is part of that process, it necessarily truncates the load address (64-bit load address doesn't fit into 32-bit LPVOID). The end result is that the debugger sees a DLL load event, but can't find any DLL at that address; so warns you.
(Would switching to 32-bit versions of Eclipse/JVM etc fix this?)
No: this is fundamental to debugging any 32-bit process on x64 (at least with 32-bit debugger). I think you would get rid of the warning if you use x64 version of GDB, but I am not sure if GDB/x64 can debug 32-bit processes on Windows (x86_64 GDB has no trouble with i386 processes on Linux due to "multi-arch" support; I don't know if "multi-arch" is present in Windows version).
I'm concerned the missing DLL errors could harm my ability to debug my program properly
You shouldn't be.
I don't see any reason my application would need to reference IESHIMS.DLL
What made you think it's IESHIMS.DLL?
More likely what you see is WoW64.dll and friends.
Every 32-bit application running on Win/x64 references WoW64.

Resources