Don't know specifically about Visual Studio, but like I told you in a previous post (posting.php?mode=quote&f=1&p=179563#pr179546), chance you can mix the generation of debug info and any optimization option. The debug info being generated in a separated file this will not change your generated binaries which will be without any debug info inside (debug info being beside in another file).raananb wrote:Edit: on a second thought, doing this will produce a different object, and the result may not apply anymore. As I already mentioned, the Debug version did not have this problem.
Using Clang on Mac (again, I can't say nothing about Visual Studio, the last one I used was Visual Studio 6.0:), the process is this one (observed through Xcode -- the official Mac way --, even if I use another IDE) :
1) Using the option "-g" for the compiler, it generates the debug infos in the object files
2) Objects are linked to produce the executable
3) I ask explicitely to extract the debug infos to a .dSym file
4) I strip out the debug info into the executable.
So the behavior of my final executable sould be the same as the one w/o generation of debug info. It is exactely the same as the one it would be without generation of debug infos and even after debug info have been removed in the final binaries, the dSym file is still able to tell what address matches what function/location in code. Since I provide the matching binary image and dSym file (same UUID), a debugger or tool to symbolicate a crash report understanding the format of the dSym (eg. DWARF) file will be able to do its job.
So, I don't know about MSVC, but I'm surprised you say it doesn't behave the same.