In Visual Studio 2015 RTM we announced Edit and Continue (EnC) support for both X86 and X64 C++ in the default Debug Engine with the VC++ 2015 toolset (v140). Over the past couple months, we’ve been working on improving the experience and supporting new configurations. In this blog post I’ll go over the improvements we made to C++ EnC for Visual Studio 2015 Update 1.
To quickly recap – Edit and Continue allows you to modify your code at runtime (while debugging) without the need to stop, recompile and start the app again! For instance, if you are debugging and notice an error in a function of your code while stopped at a breakpoint, you can modify your source file, hit Continue (a Go or Step command), and the debugger will apply your code changes to the debugged process and continue debugging with your new code! This can help speed up your Edit > Build > Deploy > Debug cycle. See our previous 2015 RTM post for further details.
2015 Update 1 EnC Improvements
- Support for Windows Store and DirectX Apps (supporting the /bigobj compiler switch): The VC++ 2015 toolset in Update 1 now supports the /ZI compiler switch (EnC switch) with /bigobj, which is enabled by default on Windows Store projects and DirectX apps.
- Support for binaries linked with /DEBUG:FASTLINK debug information: FASTLINK is a linker switch that speeds up build times (by leaving some debug information in the obj files rather than consolidating it all in the PDB), and the VC++ 2015 toolset in Update 1 now supports using EnC with FASTLINK binaries.
- Show a cancelable wait dialog during EnC: We now show a wait dialog notifying the user of the progress, keeps the UI responsive, and also supports cancelation.
- Notify user if a file was modified that doesn’t support EnC: A common complaint about EnC usability was the difficulty in diagnosing *why* an edit was being ignored by Visual Studio. This is usually due to a compiler or linker switch that is incompatible with EnC (such as not using the /ZI compiler switch or the /INCREMENTAL linker switch).
With Update 1, if a source file was modified during debugging but does not have the right configuration (such as incompatible compiler/linker switches), an error dialog is displayed with actionable information about why the edit isn’t supported.
For example, if the source file was compiled with /Zi (instead of /ZI), an edit will now fail with an error dialog and the following error (in the Error List or Output > Build):
You can choose to ignore the error by clicking “Ignore” in the error dialog.
- Reserving more memory to allow applying more edits to the binary: The memory reserved in the binary built with EnC options (/ZI compiler switch and /INCREMENTAL linker switch) has been increased to prevent the dreaded “Out of reserved address space in module [module name]” error message. With this change you will be able to make more edits before being forced to stop debugging to recompile the binary.
- Improve Instruction Pointer remapping to prevent Stale Code warnings: User feedback indicated a number of people were running into the “Could not determine new address in function X to remap the instruction pointer” warning. Here, the Instruction Pointer would not be remapped to the new (modified) code and would remain in the old (unmodified) code, and such a situation is called “Stale Code” (check out our previous 2015 RTM post for further details). We’ve made some improvements to this area to ensure that we figure out the right address to remap the IP and reduce our chances of ending up with Stale Code.
- Honorable mention – Fixed the “fatal error C1092: Edit and Continue does not support changes to data types; build required” false positive compilation error for unrelated changes: This was one of the top voted EnC bugs.
During EnC recompilation, the compiler would throw the warning “warning C4656: … data type is new or has changed since the latest build, or is defined differently elsewhere” which caused “fatal error C1092: Edit and Continue does not support changes to data types; build required” for unrelated changes. It was easy to run into this error with code using the STL.
This was caused due to an false positive ODR violation and we’ve addressed this issue in Update 1 – this warning will no longer cause a fatal error during EnC recompilation.