What's the difference between compiler and linker debug information?

Question

I am a little confused why Delphi has Debug information in linking and debug information in compiling.

What is the difference between them ?

Sporogenesis

Answer 1

Debugging option in the Compiler will add the Debug information to the DCU files.

Debugging option in the linker will put all debug found in the DCU files into the exe/dll.

if you're using something like FastMM4 or memslueth you will need both options to help you find any faults.

If your releasing code you should disable the linker option to greatly reduce your exe size ( and protect your IPR ).

If you are releasing just the DCU files ( as a 3rd party control/library ) you should turn off the compiler setting before releasing, if you are not supplying source code.

Baltic

But how does madexcept locate procedure names if i am compiling only with debugging option in the compiler ? – Sporogenesis

They're DCU's for Delphi, not OBJ's. And if you're releasing compiled code only, you might want to release two versions of the code: Compiled with and without debugging. Debugging information is not only necessary for FastMM4 and other 3rd party debuggers, it's most important for the IDE itself. – Claribel

@opc0de, take a look at the MAP files (also a Linker option): it's the easiest way to transform Address into module and procedure name. – Claribel

I've never used madexcept, but i expect youd need to enable both options, persoanlly i never disable the compiler option and just use the linker option. and Thank Cosmin for correcting my obj/dcu mistake, I need to stop using too many different compilers. – Baltic

@CosminPrund thanks for your edits. So the map file gets linked into the executable so madexcept can identify procedures from memory addresses ? – Sporogenesis

No, the map file is never linked into the exe. I'm not using Madexcept so I can't guess what it's doing. If it can guess the name of procedures on a client's computer (ie: without the MAP file) then it must be using the embedded debug information. The MAP file is nice if you want to roll something of your own: it's a TEXT file and it's human readable. Almost human readable. – Claribel

@Baltic No, madexcept works with no debugging info included at all. – Fungus

I liked OBJ version better. In the fact, DCU is merely smooth and round reinvented whee... object file. Well, a proprietary alternative to it. Delphi's integrated compiler/linker/binder just keep its user safe from the knowledge of the normal toolchain. A use of the map files to build a debug information (instead of native debugging information) is good illustration of that. – Floret

madexcept adds the map info to the exe. When you install madexcept into the IDE it automatically does this for you when you compile/build. When using the commandline compiler, you need to use a utility. IIRC it is called madexceptpath.exe and is somewhere in the madexcept installation folders. – Lave

Answer 2

The Debug information

In debug-mode runtime checking code and debug information is crammed by the compiler into the DCU files. Therefore, the whole application is larger and sometimes (depending on your settings) slower. The Debug information

The Debug Information option, in the Compiling page, is extra information about the source code, such as line numbers, variable names, and other details that are used for debugging purposes. The information is not necessary for the program to work, but it is necessary if we want to debug the program. The Debug Information is stored into the DCU files only.

If our program crashes while we are running the program under the debugger (F9) and the debug info is present, the debugger will be able to draw a connection between the crash point in our binary program (exe file) and the corresponding line in the source code. In other words, if the program crashes, the debugger will be able to show us to the line of code where the program crashed. If the debug information is not present, the debugger will be able to show only a vague message about the error. Do you want that?

To activate the debug information, we need to open the Project Options and tick the Debug information checkbox as shown below:

The same can be achieved also in the source code by using the {$D+} compiler directive. This has the same effect as activating the “Debug information” into the Project Options. Remember that the compiler directive always takes precedence over whatever is set in Project Options.

Hint: Along with the standard Debug and Release mode, we can add your own “flavors”. For example, I always have three configurations for my projects: Debug, Release, and my own defined PreRelease.

Should we release an application under debug mode?

Activating the debug information as shown above increases the size of the DCUs and takes up a bit more memory when compiling, but it does not affect the size or speed of the executable program.

Security warning: A debug version is “juicier” for a possible hacker that wants to attack our application, because he can learn more (much more) about our code when he disassembles the application.
Therefore, the executable itself should also NOT contain debug information. That being said, in many cases we might want to send an executable compiled in Debug mode to our (trusted) beta testers. If the program crashes, more useful information will be presented on screen. The DCU files are not meant to be distributed with our EXE program. They are only to be used locally, for debugging purposes.

Once we get a stable version, and we are ready to distribute our program to the customers, we must compile the program in release mode before we ship it.

If your applications are just small, less famous tools, I wouldn’t let the above warning stay in the front of your progress. However, as your applications are getting popular over the Internet (start to get 1000 downloads per day), they will start to raise one hacker’s attention. This is the point where you should start worrying about security. The same, if your application is less popular but handles some secured resources (bank accounts, ftp accounts, email servers, etc). In this case, take security seriously from the beginning.

The linker

The linker is the program that is coming after the compiler. It picks up from the DCU only the routines needed by our program and merges them into the final application (EXE) file. Therefore, the resulted exe file is smaller than the sum of all DCU files. This process is called smart linking. Some linkers can be smarter than others!

Hint for C++ programmers: In C/++ the programmer has and must take direct control over the linker, but Delphi makes the linker somehow “invisible” for the programmer. Basically, it hides the linker inside of the compilation process, but the programmer can still easily access some linker settings under Project > Options > Building > Delphi Compiler > Linking:

Remember that the compiler will not generate DCU files for the DFM files. The DFM files are converted to resources and directly integrated into the Exe file by the linker.

---

Conclusion:

As we can see, there are two settings called Debug information. The first one is in the Compiler tab and second one in the Linking tab:

While the one in the Compiler tab will add the debug information to the DCU files only, this option (in the Linking tab) will put all debug found in the DCU files into the final EXE (or DLL). This will increase the EXE file size will be about 10-20MB but won’t slow down the program.

In most cases, you can leave the “debug information” unchecked. Activate it if you debug the IDE into the IDE or if you have tools like MadShi and they tell you to activate it.

Czernowitz