In RAD Studio 10.2 Release 1 (or 10.2.1) we’ve made a number of improvements in the debugger.
Windows debugging: general quality
Do you debug multithreaded applications? You might have noticed that wait chain traversal, showing which threads were blocked on which other threads, was not working on Windows 10. We have re-enabled support and you can now debug thread interaction much more easily.
We’ve also made some changes for Delphi when a process ends or you detach the debugger. Performance should be greatly increased.
While not the debugger per se, if you use classic C++ you may be interested that CodeGuard works on Windows 10, and if you use Clang then debugging a Win32 app is improved.
Linux
There are many quality fixes in the Linux debugger in 10.2.1, including issues with placing or breaking at breakpoints, handling floating point and Extended, showing disassembly, dynamic arrays of records, and more.
Windows Creator’s Update
This is not strictly part of the debugger, but was an issue very visible when debugging. Creator’s Update drastically changed how Windows handled loading DLLs, including packages, through changes in how it handled a the import address table. A PE file contains multiple tables listing the functions it relies on from another file – for example, that it needs foo() from bar.dll. For over twenty years, our toolchains, whether Delphi or C++, have emitted multiple tables per DLL as well, as a performance optimisation when generating the final binary.
Windows Creator’s Update changed how it processed these tables, meaning that when there were multiple tables per DLL a DLL would be loaded and unloaded once per table. When starting an app normally, this is negligible. When debugging, this also triggers loading and unloading debug info, meaning that starting an app with the debugger attached was very slow. This happens in Visual Studio as well with PE files containing these tables. Microsoft plan to fix this in the Fall Update, but unfortunately have not been forthcoming with a hotfix more quickly.
10.2.1 changes our linker output, and so loading a process while debugging will now be much faster. If you have a BPL or DLL from 10.2.0, such as one created by a third party, you can still use that BPL or DLL but you should rebuild it to avoid the slowdown imposed by the Creator’s import module loader. Contact third party vendors for an updated version built with the 10.2.1 toolchain.
Marco’s blog has more details on 10.2.1 and an older post on the original issue.