The linker is a core part of the C++Builder toolchain – after all, it’s the part that collects the compiler’s output and creates your final binary, so it’s hard to understate its importance! – and because it brings the entire application together at once, it can use a lot of memory. C++Builder 10.4.2 is not the first release where we’ve introduced linker improvements: making the linker large address aware, tuning the linker to today’s typical applications, and documenting useful flags for tweaking linker behaviour if you find the linker struggles with your application. (Not to mention adding useful features like detecting mixes of classic and clang objects when linking, which helps you catch an invisible issue affecting your app runtime stability – i.e. use this to ensure your app doesn’t contain a common mistake, and is stable.)
In C++Builder 10.4.2, we’ve made a big improvement to the Win64 linker known as Split DWARF, something we’re bringing to Windows from the Unix world.
Why the Odd Names?
Object files – the compiled form of each compilation unit, i.e. each .cpp file – are stored in different object formats. On Win64, C++Builder uses 64-bit ELF, which is normally a format used on Linux. It stands for Executable and Linkable Format, but we suspect has its real origin in fans of Tolkien — because the ancillary debug information format, for holding debug info for each object, is named DWARF. This one definitely is a pun (see page 2 of this PDF.)
Split DWARF is not the result of a D&D tavern fight, or even a Calvino novel. In fact, it’s a way of splitting the debug information out so the linker doesn’t have to handle it.
This is the secret. What’s the best way of reducing the amount of memory the linker needs when linking your app?
It’s almost ridiculously simple. Giving it less to link.
Splitting Debug Information
Typically, when building your application in debug mode, or with any units with debug information turned on, the debug information is contained in the object file along with the compiled code. The linker reads both and creates the final binary – your EXE or DLL – and that, too, contains both compiled code and debug information. This is the main reason a debug EXE is so much bigger than a normal release-mode app.
Split DWARF processes the object file and splits the debug information out into its own file that sits side-by-side, a .dwo file. A tiny stub remains in the original object file that the debugger can read to know where to find the debug information.
To turn it on, in your Project Options go to Building > C++ Compiler > Debugging, and find the “Use Split DWARF” option.
Turn it on.
Expand the option (click the > caret) and choose an absolute path where the debug information should go – that is, make a path that is not a relative path, e.g. begins with c: or d:. This is required to ensure the debugger can find the debug information.
And that’s it. For more info, you can find our documentation here. You can use the great new Win64 debugger (with awesome features, like inspecting STL types – more has been added since that blog) while giving your linker much less to link in C++Builder 10.4.2!