incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Farid Zaripov" <Farid_Zari...@epam.com>
Subject RE: svn commit: r588290 - /incubator/stdcxx/branches/4.2.x/etc/config/windows/projectdef.js
Date Tue, 30 Oct 2007 18:24:40 GMT
> -----Original Message-----
> From: William A. Rowe, Jr. [mailto:wrowe@rowe-clan.net] 
> Sent: Tuesday, October 30, 2007 7:50 PM
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: svn commit: r588290 - 
> /incubator/stdcxx/branches/4.2.x/etc/config/windows/projectdef.js
> 
> > 2. in dynamic builds the source pdb and the binary pdb both
> >    generating in OutDir using the single file with the name
> >    libstdxx.pdb.
> 
> This one is more problematic.  Source and Binary .pdb's are 
> two different file formats, you've corrupted the one creating 
> the other.

  I don't think so.

>From http://support.microsoft.com/kb/121366
-----------------------
By default, when you build projects generated by the Visual Workbench,
the compiler switch /Fd is used to rename the .PDB file to
<project>.PDB. Therefore, you will have only one .PDB file for the
entire project.

When you run makefiles that were not generated by the Visual Workbench,
and the /Fd is not used with /Zi, you will end up with two .PDB files:
*	VCx0.PDB (where "x" refers to the major version of the
corresponding Visual C++, either "2" or "4"), which stores all debugging
information for the individual .OBJ files. It resides in the directory
where the project makefile resides.
*	<project>.PDB, which stores all debugging information for the
resulting .EXE file. It resides in the \WINDEBUG subdirectory.
Why two files? When the compiler is run, it doesn't know the name of the
.EXE file into which the .OBJ files will be linked, so the compiler
can't put the information into <project>.PDB. The two files store
different information. Each time you compile an .OBJ file, the compiler
merges the debugging information into VCX0.PDB. It does not put in
symbol information such as function definitions. It only puts in
information concerning types. One benefit of this is that when every
source file includes common header files such as <windows.h>, all the
typedefs from these headers are only stored once, rather than in every
.OBJ file.

When you run the linker, it creates <project>.PDB, which holds the
debugging information for the project's .EXE file. All debugging
information, including function prototypes and everything else, is
placed into <project>.PDB, not just the type information found in
VCX0.PDB. The two kinds of .PDB files share the same extension because
they are architecturally similar; they both allow incremental updates.
Nevertheless, they actually store different information.
-----------------------

  As I understand the source and binary pdb files store the different
information, but may be combined in the single pdb file since the
format for the both pdb files is the same and both pdb's supports
merging
the changes without corrupting the other data during the incremental
updates.

  So I think first we need to decide whether the information from
the source pdb is needed to the library users in dynamic builds or not?
- If no, then we can generate the source pdb in IntDir with the default
name
  (this is the same that revert the patch for dynamic builds).
- If yes, then we can use the single pdb file in OutDir, or generate two
  pdb files libstdxx.pdb and libstdxx_src.pdb both in OutDir.

> You might want to deploy the source pdb as 
> $(IntDir)/stdlibxx_src.pdb - which is as temporary as any of 
> the object files in the build.  But - if you tweak one file 
> and recompile, you won't have problems with the resulting 
> $(OutDir)/stdlibxx.pdb losing any context from the previous 
> .pdb for the modules that aren't rebuilt.
> 
> >   So you propose to revert the patch only for dynamic builds?
> 
> Don't revert, you were on the right track :)  I'd just take 
> this one step further as I mentioned above.

Farid.

Mime
View raw message