/Zi vs /Z7 - static linking

Question

We had a strange problem which I tracked down to being a problem with mismatching calling conventions. I wanted to verify this theory, and checked what debug options are available in cl.exe. When I read though our build system, I noticed that someone had changed Zi to Z7 for debug builds (before I started working with this project), and there was no documentation specifying why this change had been made. So I changed it to Zi, and was happy to see that the error reported when the application crashed indicated that there might in fact be a calling convention problem.

So, why would anyone disable Zi, and chose to Z7? With Z7 it just crashed, with no extra information. Zi guessed (correctly in this particular case) what was wrong. It could potentially have saved me quite a few hours debugging if Zi would have been used from the beginning.

I changed to Zi in our build system, and committed the changes.

A few days later, a colleague asked me why he could no longer step into certain functions with the debugger.

That's when we noticed the problem with Zi.

To summarize: We build several .lib files, which we statically link into a .dll. For each lib, a separate .pdb file is created. But the debugger only appears to support _one_ pdb file per module (.dll). So we can debug the functions which are declared in the .dll's code, but not the ones in the statically linked libraries.

We have the choice of (apparently) better debugging features with Zi, but not being able to step into functions which were linked in from libs, or we can use Z7, and step into functions, but not get potential helpful hints in case of a crash.

Is there a way we can get the best of both worlds? Something like a .pdb merge utility, so we can put the statically linked libraries' pdb files in the dll's pdb file?

Answer 1

Hello Bliy,

With option /Zi, we produce a program database file (pdb file) which stored information for debugging, for exammple, variables' type and line numbers, while with option /Z7, there is no pdb file, all the information for debugging is stored in the .obj file. I do not really know why he disables Zi but using Z7, maybe he wanted to avoid generating the pdb files.

As for the second issue, so you mean we could not debug into the static library when build it with /Zi option? well, I am not sure which version of Visual Stduio do you use, however, in my test project, it works file. Will you please create a new project and evaluate if the issue still occur? As we could see, using /Zi option will generate a .pdb file for the static library project. we could use a a Process Monitor to see if Visual Studio has openned the .pdb file of our library and make sure it is the right .pdb file we want.

For more information about the compiler options /Z7, /Zi and /ZI, please refer to:
http://msdn.microsoft.com/en-us/library/958x11bc(VS.80).aspx

Thanks

---

Please remember to mark the replies as answers if they help and unmark them if they provide no help.
If you have any feedback, please tell us.
Welcome to the All-In-One Code Framework!

Answer 2

Consider this case:

Department A develops A.lib (and associated header files) and generates a A.pdb to go with it.

Department B develops B.lib (and associated header files) and generates a B.pdb to go with it.

Department C get the headers, the libraries and the pdb files from departments A and B.

Department C have a Visual Studio project for a DLL, which statically links against A.lib and B.lib. Dept. C can request certain source files from depts. A and B for debugging purposes, but are unable to completely rebuild A.lib or B.lib.

Now, department C finds a bug in their DLL which may in fact be a problem in A.lib or B.lib. They request a few of the relevant source codes for A.lib and B.lib, so they will be able to step into A and B's functions. The question is what dept. C needs to do with the .pdb files they got from A and B in order to get the Visual Studio debugger to recognize them, so that they can step into the functions in A.lib and B.lib which are called from dept. C's DLL.

I don't doubt that you have it working in your environment, but I need to know exactly what I need to do with the pdb-files in order for Visual Studio debugger to be able to step into A.lib and B.lib's functions. Does one simply place them beside the .lib files during link, and the linker will automatically merge the A.pdb and B.pdb into C.pdb?

Answer 3

Hello,

"The question is what dept. C needs to do with the .pdb files they got from A and B in order to get the Visual Studio debugger to recognize them"
There are a couple of way to let Visual Studio Debugger know where to find the pdb files of our modules.
 1. place the pdb files in the output folder of our project (Project C in this case). Since Visual Studio will automatically search the path containing the exe file.
 2. place the path to the Symbols (Tools -> Options -> Debugging -> Symbols), there is a Symbols files (.pdb) locations box.
 
Also, please note, to step into the source code, we need the pdb file which containing the source information.

Best regards,

---

Please remember to mark the replies as answers if they help and unmark them if they provide no help.
If you have any feedback, please tell us.
Welcome to the All-In-One Code Framework!