What's New in C++Builder 10.2: Part 3 - Debugging
RAD Studio 10.2 Tokyo is out now, and I'd like to let you know some of what you can expect to see new on the C++Builder side. While the majority of work is for Linux, which will be available for C++ in 10.2.1, we've worked on three key areas:
- Improved linking
- Improved code generation
- Improved debugging
Today I want to discuss what's new for debugging.
Win32 and Win64 Clang-enhanced compilers
As you probably already know, we using Clang as the basis for our modern generation of compilers, on mobile, Linux, and also Windows. The 'classic' compiler (bcc32) will remain around for the foreseeable future, but the Clang-based ones are where our technology is heading.
We've made some significant improvements to the debugging experience for the Windows Clang-based compilers. Some address bugs, such as ensuring the class names are always shown in the call stack, but in this post I want to focus on variable evaluation.
In Win32 and Win64, there were sometimes problems evaluating local and/or parameter variables. The reason was related to variable behaviour even at optimization level 0, and spilling registers to the stack. You can now always evaluate a local variable.
In Win64 we've additionally gone even further with debug info, fixing a problem when there are multiple variables with the same name in different scopes. These weren't always able to be differentiated correctly.
In this screenshot you can see two blocks with the same variable names but different values, as well as a parameter, and the variables being correctly identified and displayed in the Local Variables and Watches views. (This also works when a parameter has the same name as a local variable.)
Smaller debug info via external types
In 10.2, we've added a feature to the Win32 Clang compiler that was already present in the classic bcc32 compiler: external type files. What problem does this solve? A good example is when using the VCL, which has many thousands of types: many individual units may refer to VCL types and include debug info they, validly, need; that info was correctly and validly included - and duplicated. This meant that debug data could often be very large, with attendant problems relating to linking it and loading it.
This feature is already in the classic bcc32 compiler, and is on by default - you may not even know you're using it!
To turn it on for Win32 Clang, go to the project options, C++ Compiler, Pre-compiled headers. You will see two 'External type files' options, one for the classic compiler and one for Clang. Turn on the one for Clang and rebuild. Make sure that your precompiled headers include the includes and declarations for types you want - the VCL or FMX would be good examples, and both are probably already in your precompiled header.
Why is this only the Win32 compiler? The Win64 compiler uses a different debug format and is much less affected by debug info size.
This feature may count for codegen more than debugging. There were a few bugs in the Clang compiler's exception handling, mostly potential memory leaks so that you might have leaked a small amount of memory per exception. While not affecting most applications, this is important for long-running or 24/7 applications such as a server app. These are now resolved.
We would encourage you to make use of the robust exception handling present in the Clang compilers. This is the third release of C++Builder with a Win32 Clang-enhanced compiler, and the eighth with a Win64 Clang-enhanced compiler, and we're encouraging migration in general: regard better exception handling as yet another benefit!
10.2 is out now!
C++Builder 10.2 has some great new features, and some important quality fixes, in key areas of linking, code generation, and debugging. We hope you find using it productive! It is out now!
Wednesday, 22 March 2017
Thanks for addressing these issues in this release. I have a comment. You said "The Win64 compiler uses a different debug format and is much less affected by debug info size.". However as you may remember we are facing this issue when we use win64 and having 750 MB of debuggable executable (32 bit clang version is around 20 MB). Thanks to your suggestions, we dropped this amount to 550 MB now and it seems rest is the fault of the compile/linker/debugging system. I will test this today with the new release and let you know.. Thanks again anyway.
Please login first in order for you to submit comments
- Page :
In the past we were unable to add the call stack to the debug info. Is that possible now?