Bad MiniDump "core" file generation
cristianadam opened this issue · comments
At https://github.com/cristianadam/MaxiDump I have a project that will create a MaxiDump.dmp
file when the project is run.
I've attached 3 screenshots of Qt Creator using lldb:
-
Unstripped
MaxiDump.exe
showed the bad source line and the correct stacktrace (due to DWARF information) -
Stripped
MaxiDump.exe
with LLVM MinGW's lldb showed only assembly with bad stacktrace -
Stripped
MaxiDump.exe
with the official llvm.org binaries (MSVC flavor) showed also assembly but with proper stacktrace.
For number 3 I've tried with a copy of "c:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\DIA SDK\bin\amd64\msdia140.dll"
in "c:\Program Files\LLVM\bin"
and without.
I know that the llvm.org lldb binary is built using DIA SDK.
Then I decided to test clang-cl 16.0.6 and test the two lldb.exe versions.
The LLVM MinGW (stripped) binary and dmp files:
MaxiDump.exe 15,872 bytes
MaxiDump.dmp 29,878,132 bytes
The clang-cl binary and dmp files:
MaxiDump.exe 15,360 bytes
MaxiDump.dmp 28,460,315 bytes
They were more or less the "same".
Then I loaded the "core" file and the results are:
-
MSVC lldb.exe loaded the source file, but pointed at the wrong line, also the stack trace was missing one level
-
MinGW lldb.exe loaded the source file at the right location and the stacktrace was fine!
Since MinGW lldb.exe can load a MiniDump file produced by clang-cl just fine, I assume there is a bug in the generation step of the MiniDump when using the llvm mingw binaries.
Note that for Qt Creator 11 I had to apply one patch https://codereview.qt-project.org/c/qt-creator/qt-creator/+/492209 that would allow the "OK" button to be enabled. You can add a space " " after the name of the dmp file if you don't have the patch.
By adding changing the CMakeLists.txt
to target_compile_options(MaxiDump PRIVATE -fms-extensions -g -gcodeview)
I've got the following binaries with LLVM MinGW:
MaxiDump.exe 15,872 bytes
MaxiDump.dmp 29,988,914 bytes
Then loaded the core into Qt Creator and ... IT WORKED !!!
-g -gcodeview
was the missing link.
Out of curiosity, may I ask some question?
- In the first post, you have mentioned about stripping the binaries. Is there any difference between the stripped binaries with llvm-mingw vs. msvc flavored llvm (like PE sections etc.)?
- Is
-fms-extensions
option related to this issue?
Out of curiosity, may I ask some question?
- In the first post, you have mentioned about stripping the binaries. Is there any difference between the stripped binaries with llvm-mingw vs. msvc flavored llvm (like PE sections etc.)?
Stripping is mostly relevant if you want to use PDB debug info with LLDB. Since most toolchain supplied files contain some DWARF debug info, if you build an executable with CodeView/PDB debug info (-g -gcodeview -Wl,--pdb=
), the resulting executable will still have a little bit of DWARF info. When LLDB loads that executable, it finds DWARF and only uses that, and doesn't try to look for a PDB file.
So if you want to use a PDB file with LLDB, with a mingw toolchain, you currently need to strip the binary to get rid of the misleading and incomplete DWARF. (I'm considering if this should be changed/improved somehow.)
- Is
-fms-extensions
option related to this issue?
No, it's related to the testcase and how it catches a crash.
Also, to clarify the usecase. If building an executable with llvm-mingw and intending to debug it with LLDB (or GDB), the default debug info format of DWARF works just fine.
If wanting to debug with WinDbg or MSVC, which don’t support DWARF but only PDB, one can add the options -g -gcodeview -Wl,--pdb=
to generate a separate PDB file instead.
If you’ve got a mingw-built executable with debug info in PDB form and want to debug that with LLDB, that’s when you hit the case when you currently need to strip the executable.