On Thu, 20 Jul 2023, Cristian Adam via Development wrote:
WinDbg didn't work, but lldb.exe itself works:
lldb MaxiDump.exe --core MaxiDump.dmp
I've updated cristianadam/MaxiDump (github.com) with this new information.
FWIW, I didn't test minidumps, but I tested that PDBs currently do work
with at least WinDbg and MSVS. My test procedure was:
- Grab
https://github.com/mstorsjo/llvm-mingw/blob/master/test/hello-exception.cpp
as testcase. Change the source to intialize it with "crash = true" to
trigger the crash case without giving command line parameters to the
executable.
- Compile with llvm-mingw-20230712-ucrt-x86_64 with "clang++
hello-exception.cpp -o hello-crash.exe -g -gcodeview -Wl,--pdb= -static"
- With WinDbg: File, Open Executable, locate hello-crash.exe. Debug, Go.
And I get the crash location in source opened, with call stack and local
variables inspectable at least.
- With MSVS: File, Open, Project/Solution, locate hello-crash.exe. Debug,
Start Debugging. Source for the crash site is opened, call stack and local
variables seem reasonable.
- With LLDB: As LLDB supports both DWARF and PDB, it will prefer DWARF if
such debug info was found. As other toolchain files that are linked in
happen to have some DWARF in them, the executable will have a little bit
of such debug info available, so LLDB ends up using that and not looking
at the PDB. So first I run "strip hello-crash.exe" to get rid of the
residual DWARF, after that "lldb hello-crash.exe" followed by "run", and I
get the crash easily visible. (This case could probably be made nicer.)
If LLDB worked for you without, possibly without stripping out residual
DWARF, but WinDbg didn't, it sounds like it might have ended up using
DWARF after all?
// Martin
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
