PDB database options and file location

[markus]

Hello,

now with Fortran Compiler Version 2013.0.089 the option /pdbfile seems to be ignored at all. Documentation says it is equivalent to /Fd, but only /Fd works as desired.

Regarding pdb files you may look at related topics:
http://software.intel.com/en-us/articles/fd-ignored-for-specifying-pdb-file-name
http://software.intel.com/en-us/forums/topic/284441

My questions about this topic:

1) Has using pdb files the same functionality as using /Z7 (storing debug information in object files)? I ask this because of apparant differences in file sizes.

2) Is using pdb databases multiprocessing save? (Concurrent compiler runs access the same pdb file).

3) Is using pdb databases recommended for concurrent compiler runs? (Locked file contents?)

4) Why is it the default to create the pdb database in the current working directory as vcxxx.pdb? Different compiler runs obviously use the same pdb database. Is the pdb database definition general enough to deal with this? (This is also related to the next question.)

5) The linker link.exe not only accesses pdb-files but also writes one. With the /pdb:xxx option you can define the resulting pdb-file. Is it save to use the same the compiler generates with /Fd?

Can someone please bring in some light about pdb databases? For a programmer (like me) it would be very helpful to understand what is going on behinde the sceenes.

Markus

[Lorri_M_Intel]

Lots of questions; let me try to answer them all. First - no, /Fd and /pdbfile:xx are not equivalent. We should fix the documentation, (I'll talk to our doc person) but that doesn't answer any of your other questions :-) Second, you're correct; there are two pdb files created during the compile/link stage; by default one is named vcNN.pdb the other named .pdb. Of these, NN is the version of Microsoft Visual C/C++ and is created during compile time, and is the name of the executable and is created during link time. Now some history. /pdbfile came to ifort as a compatiblity switch with CVF, where it was synonymous with /Fd. WIth CVF, we were able to create .pdb files because Compaq (at the time) had a development agreement with Microsoft for header files describing the pdb file format. That agreement did not transfer to Intel right away, so the only behavior available was to name the executable created at link time. Finally, in 12.0 we added the ability to create .pdb files, which improves the debug information in a variety of ways. For a number of reasons, this was implemented via the /Fd switch, and /Fd was used to name the pdb file created at compile time. Given all this, let me try and answer your specific questions: 1) Has using pdb files the same functionality as using /Z7 (storing debug information in object files)? I ask this because of apparant differences in file sizes. I think it has more functionality. 2) Is using pdb databases multiprocessing save? (Concurrent compiler runs access the same pdb file). Yes, it is safe to have multiple processes *writing* to the compile-time .pdb file. However, the linker locks the file when it reads it, before performing the link step and to generating its own .pdb file. If you're only creating one executable from your set of source files, there are no issues. If your project is more involved and/or interesting, and could be performing a link at the same time as another thread is still compiling, then you will get build-time errors. However, for the 99.9% case, where you are creating a single executable from the set of object files, there are no multi-processing issues. 3) Is using pdb databases recommended for concurrent compiler runs? (Locked file contents?) I think I answered that question above, yes? 4) Why is it the default to create the pdb database in the current working directory as vcxxx.pdb? Different compiler runs obviously use the same pdb database. Is the pdb database definition general enough to deal with this? (This is also related to the next question.) Because that's what Visual C/C++ does. 5) The linker link.exe not only accesses pdb-files but also writes one. With the /pdb:xxx option you can define the resulting pdb-file. Is it save to use the same the compiler generates with /Fd? I'm going to say "No" because Visual C/C++ does not. I hope this helps -- --Lorri