Laurens

Last night and this morning I continued working on this and I have some more information that hopefully can give some insights. Using LLDB and after running `map2pdb.exe -exclude:system*;dx*;cx* -bind Tester.map` I see that the stacktrace in my code always looks the same: (lldb) thread backtrace 1 thread #1 frame #0: 0x7565113c win32u.dll`NtUserWaitMessage + 12 frame #1: 0x00a605e6 Tester.exe`__dbk_fcall_wrapper + 2927526 frame #2: 0x00a5f5b8 Tester.exe`__dbk_fcall_wrapper + 2923384 frame #3: 0x02791c90 Tester.exe`__dbk_fcall_wrapper + 33538640 frame #4: 0x02791cf7 Tester.exe`__dbk_fcall_wrapper + 33538743 frame #5: 0x03e092d2 Tester.exe`__dbk_fcall_wrapper + 57096338 frame #6: 0x03e0931f Tester.exe`__dbk_fcall_wrapper + 57096415 frame #7: 0x05753071 Tester.exe`Tester + 93 frame #8: 0x76d07d59 kernel32.dll`BaseThreadInitThunk + 25 frame #9: 0x779ab74b ntdll.dll`RtlInitializeExceptionChain + 107 frame #10: 0x779ab6cf ntdll.dll`RtlClearBits + 191 LLDB always refers to `__dbk_fcall_wrapper`, but not to the actual method. I also noticed that running the same program in WinDBG, gives no stackstrackes at all. Running in WinDBG with a DBG-file created with `map2dbg` gives stacktraces with correct method references. (Although the sourcecode references do not work yet). I really love to use LLDB (from VS Code, because the editor performs so much better for large projects than the Delphi IDE) and I think we can get close to get it working, but correct callstacks and method/source references are absolute necessary for this. I hope someone can put me in the right direction.

This is a really nice topic and the first PDB-tool I have found that works fast. I am trying to get debugging working in VS Code for Win32 using LLDB. The debugger runs, but does not shows the correct callstack/symbols and I hoped to fix this using the PDB-output from this tool. However, I cannot get it working yet. Has anybody here tried this?

Ok, that is unfortunately. Then I will just add the specific `mmdep`-files to the repo for now. Thanks!

Hi @Uwe Raabe, I try to do the same. However, `MMT_UDA` expects a mmdep-file (which can be generated using the UI), but is there also a way to generate the mmdep-file using the commandline so I can also integrate this in our CI-pipeline?

Correct, the fork on GitHub (https://github.com/DelphiCodeCoverage/DelphiCodeCoverage) is the most recent one. I would really appreciate if you send your example to me in a PM if you have one (or create an issue in the GitHub project) so we can fix it as soon as you put your hands on the issue.

Are you using a recent release? In march this year I have fixed an issue with spurious crashes in multi-threaded code where the breakpoint was not correctly cleared (and could cause the CPU to execute a NOP where a real instruction should be). I have seen the same result once, but several years ago, do you a minimal workable example? If so, I would appreciate if you create an issue so we can investigate and fix it. The DelphiCodeCoverage tool is a good tool to start with. I prefer to integrate it to more common tools like SonarQube. We use this for analyzing our Delphi, C# and TypeScript code in one tool.

I have just published an updated version our SonarQube Delphi plugin which supports Sonar 7.9 LTS and also the latest 8.2 version, see https://github.com/mendrix/SonarDelphi. If you combine this with the DelphiCodeCoverage tool (see https://sourceforge.net/projects/delphicodecoverage/) and DUnitX (including the additional file in our SonarQube repository) you have a fully functioning static analyser AND codecoverage for Delphi. I think this is the best combination so you don't have to use several tools together (like FixInsight).