Bad MiniDump "core" file generation

[Cristian Adam]

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:

1. Unstripped MaxiDump.exe showed the bad source line and the correct stacktrace (due to DWARF information)

   

2. Stripped MaxiDump.exe with LLVM MinGW's lldb showed only assembly with bad stacktrace

   

3. 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:

1. MSVC lldb.exe loaded the source file, but pointed at the wrong line, also the stack trace was missing one level

   

2. 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.

[Cristian Adam]

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.

[Biswapriyo Nath]

Out of curiosity, may I ask some question?

1. 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.)?
2. Is -fms-extensions option related to this issue?

[Martin Storsjö]

Out of curiosity, may I ask some question?

1. 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.)

2. Is -fms-extensions option related to this issue?

No, it's related to the testcase and how it catches a crash.

[Martin Storsjö]

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.