Skip to main content
gamedev.net
🔒 Locked

precompiled headers taking executable space?

Started by Falken42 Jan 17, 2008 at 6:51 AM 6 replies 2.3k views
Original Post
Falken42
Falken42
Hello all, I noticed something strange when browsing the .map file of a project I've been working on recently under VS2005. There appears to be some kind of data related to precompiled headers (at least, that's my guess from the generated symbol name) being placed into the executable. Here's an extract from the .map file: 

 0003:00000518       ___@@_PchSym_@00@UxlowufhrlmUhixUyzhvUxuurovUyfrowUdrmDCUnzhgviRhnzooUkivxlnkOlyq@ 00414518     master-small-cffile:precomp.obj
 0003:0000051c       ___@@_PchSym_@00@UxlowufhrlmUhixUyzhvUxuoryxUyfrowUdrmDCUnzhgviRhnzooUkivxlnkOlyq@ 0041451c     master-small-cflibc:precomp.obj
 0003:00000640       ___@@_PchSym_@00@UxlowufhrlmUhixUyzhvUxulhUyfrowUdrmDCUnzhgviRhnzooUkivxlnkOlyq@ 00414640     master-small-cfos:precomp.obj
 0003:00000644       ?precalcUsecDiv@Tick@CFOS@@0MA 00414644     master-small-cfos:tick.obj
 0003:00000648       ?precalcMsecDiv@Tick@CFOS@@0MA 00414648     master-small-cfos:tick.obj
 0003:0000064c       ?resolution@Timer@CFOS@@0IA 0041464c     master-small-cfos:timer.obj
 0003:00000650       ?tickFrequency@Tick@CFOS@@0_KA 00414650     master-small-cfos:tick.obj
 0003:00000658       ?initialTick@Tick@CFOS@@0_KA 00414658     master-small-cfos:tick.obj
 0003:00000660       ___@@_PchSym_@00@UxlowufhrlmUhixUhmwUxuhlfmwUyfrowUdrmDCUnzhgviRhnzooUkivxlnkOlyq@ 00414660     master-small-cfsound:precomp.obj
 0003:00000694       ___@@_PchSym_@00@UxlowufhrlmUhixUyzhvUxunvnUyfrowUdrmDCUnzhgviRhnzooUkivxlnkOlyq@ 00414694     master-small-cfmem:precomp.obj
 0003:00000698       ___@@_PchSym_@00@UxlowufhrlmUhixUfgroUxufgrohUyfrowUdrmDCUnzhgviRhnzooUkivxlnkOlyq@ 00414698     master-small-cfutils:precomp.obj
 0003:0000069c       ___@@_PchSym_@00@UxlowufhrlmUhixUhmwUxunfhrxUyfrowUdrmDCUnzhgviRhnzooUkivxlnkOlyq@ 0041469c     master-small-cfmusic:precomp.obj
 0003:00000820       ___@@_PchSym_@00@UxlowufhrlmUhixUhmwUxuzfwrlUyfrowUdrmDCUnzhgviRhnzooUkivxlnkOlyq@ 00414820     master-small-cfaudio:precomp.obj
 0003:00000824       ___@@_PchSym_@00@UxlowufhrlmUhixUfgroUxuzwgUyfrowUdrmDCUnzhgviRhnzooUkivxlnkOlyq@ 00414824     master-small-cfadt:precomp.obj
There seems to be one symbol for each library I'm linking with. Each library uses a precomp.cpp file to precompile the headers, hence the reference to precomp.obj. Does anyone know what these symbols are, and why they being linked in? I personally see no reason for any kind of precompiled header data to be placed into the final executable. Any ideas on how to get rid of them (except for the obvious of disabling precompiled headers :) ) would be greatly appreciated.
jbadams
jbadams
Consider for a moment, if the code in your precompiled headers is not included in the final executable, how do you expect your program to work when it tries to access those functions or variables?

Precompiled headers cut down on compilation time, not executable size.

//EDIT: Some reading material.
- Jason Astle-Adams
Falken42
Falken42
Quote:
Original post by jbadams
Consider for a moment, if the code in your precompiled headers is not included in the final executable, how do you expect your program to work when it tries to access those functions or variables?

Of what "code" are you referring to, exactly?

All of the functions and variables that are being used in my executable have their own specific link address and separate entry in the .map file. I am specifically referring to the symbols that have this magic "___@@_PchSym_@00@" prefix.

Quote:
Precompiled headers cut down on compilation time, not executable size.

I'm perfectly aware of that, but I was not aware that use of precompiled headers actually increase executable size.
jbadams
jbadams
Quote:
Original post by bpoint
Quote:
Precompiled headers cut down on compilation time, not executable size.

I'm perfectly aware of that, but I was not aware that use of precompiled headers actually increase executable size.
Sorry, I thought you were comparing that increase to not including them at all rather than to still including the libraries but not using precompiled headers, my mistake.

- Jason Astle-Adams
Evil Steve
Evil Steve
Damn, my reply got lost in the "Out of disk space" error...

if the precompiled headers are compiled, then the compiler will surely be generating code for them, which means it'll need to reference it some how. So generating symbols for the precompiled header doesn't surprise me in the least.

Have you tried a version of your exe with and without PCH to see if it changes the size of your EXE?
SiCrane
SiCrane
It's just debugging information. To strip it out, turn off debugging information generation (don't use any of the /Z flags when building the project).
Falken42
Falken42
Quote:
Original post by Evil Steve
if the precompiled headers are compiled, then the compiler will surely be generating code for them, which means it'll need to reference it some how. So generating symbols for the precompiled header doesn't surprise me in the least.

But why would the linker actually need to export those symbols into the executable?

Quote:
Have you tried a version of your exe with and without PCH to see if it changes the size of your EXE?

There doesn't seem to be any actual size difference in the .exes with or without PCH, but if these magic precompiled header symbols are small enough, then this could just be due to padding within the section itself. It's difficult to tell without the VS2005 linker specifying the size of the symbol in the .map file, but they look like they might only four bytes.

With PCH disabled however, these magic symbols were not listed in the output .map file.

Quote:
Original post by SiCrane
It's just debugging information. To strip it out, turn off debugging information generation (don't use any of the /Z flags when building the project).

This is a master build, with full optimizations and no debugging information.

Even though they are small, it still bothers me that they're there...
Falken42
Falken42
Actually... nevermind.

I just realized that the linker is putting these magic PCH symbols into the .bss section:
 0003:000001f0 000006a0H .bss                    DATA


So they aren't taking any executable space at all, since it's uninitialized data. I guess can live with a few extra bytes of memory being taken for some weird symbols. :)

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.