Release with debug information

Hi,
I am using Visual studio 2005 and would like to set up a "Release with debug information" build configuration. I created a sample MFC solution and to it added:

=====

std::vector< std::wstring > textContainer;
textContainer.push_back( _T( "one" ) );

std::vector< int > intContainer;
intContainer.push_back( 15 );
intContainer.push_back( 64 );

int p=0;
p = 3;
p *=2;
p = 9;

=====

I modified the release build as per http://msdn.microsoft.com/en-us/libr...=vs.80%29.aspx to have:

Enable /Zi.
Select/INCREMENTAL:NO.
Select /DEBUG:Yes.
Select /OPT:REF.
Select /OPT:ICF.

After doing this and compiling the release build, I can see that a .pdb file is created. When running the software, I was still unable to debug through and view the values of any of the test code above. I'm missing something but I don't know what. Can anyone offer any suggestions please?
Thanks,
Patrick

Define "unable to debug through and view the values".
How did you try to debug?
Is it the complete code or just a short snippet?

Besides, there is a MSDN description of some of your compiler options:

Quote:

---

• Use /OPT:REF to eliminate functions and/or data that is never referenced.
• Use /OPT:NOREF to keep functions and/or data that is never referenced.

By default, LINK removes unreferenced packaged functions....

---

Did you turn on Generate Debug Info in the link settings too?

@VictorN I created a new "MFC Application" solution and added the test code above to the bottom of the application's ::InitInstance(). This was the entirety of the code that I added. I put a breakpoint at the first line of the additional code and stepped over each line of code. I was not able to see the values of any of the variables. I tried a few of the /OPT switches but didn't see any difference, I still could not see the contents of the variables while debugging. Is it that you can't see the contents of a std::vector on a release build?
@GCDEF yes as per the link in the original post, "Generate debug info" is set, this is the /DEBUG switch.

Quote:

---

Originally Posted by pocruadhlaoich

@VictorN I created a new "MFC Application" solution and added the test code above to the bottom of the application's ::InitInstance(). This was the entirety of the code that I added. I put a breakpoint at the first line of the additional code and stepped over each line of code. I was not able to see the values of any of the variables. I tried a few of the /OPT switches but didn't see any difference, I still could not see the contents of the variables while debugging. Is it that you can't see the contents of a std::vector on a release build?
@GCDEF yes as per the link in the original post, "Generate debug info" is set, this is the /DEBUG switch.

---

Turn off (choose Disable) the C++ optimizations and rebuild your program.

You're trying to debug an optimized build, and you can't do that since the final object code is far different than the code you see as the source (lines have been moved, removed, etc., variables removed/moved, etc.).

Edit: Do what I stated (disable optimizations) from the C++ options in the project settings. I have never had to do anything with "OPT:REF/NOREF" to debug a release version successfully.

Regards,

Paul McKenzie

Hi Paul,
yes you are right. Optimisation was by default set to "Maximise speed /O2". By setting it to "Disabled /Od", then I am able to debug and view the values of the variables as they change. My goal though is to create a "Release with debug information" build, so if you have a release build that has been set to disable optimisations, then is it really a release build? Will it run any faster or be any different than a typical debug build?
Thanks,
Patrick

Quote:

---

Originally Posted by pocruadhlaoich

Hi Paul,
yes you are right. Optimisation was by default set to "Maximise speed /O2". By setting it to "Disabled /Od", then I am able to debug and view the values of the variables as they change. My goal though is to create a "Release with debug information" build, so if you have a release build that has been set to disable optimisations, then is it really a release build? Will it run any faster or be any different than a typical debug build?

---

You're getting confused with a "debug build" and a build with debigging information included. There are two independent and separate things here, programs compiled with/without optimizations, and programs compiled with/without the _DEBUG preprocessor setting set.

When you say "debug build", are you talking about a build that is set with the _DEBUG preprocessor switch on? If you are, then nothing stops you from turning on optimizations for such a build. As a matter of fact any configuration can have debug information added or removed from it, and optimizations set or not set. So you have a myriad of different combinations possible when it comes to building a program.

Now, a build with _DEBUG preprocessor is different than a build that doesn't have _DEBUG defined. Special structures, variables, etc. will be compiled into the code (that's what the #ifdef _DEBUG is all about if you look at various system #include files), causing the code to be different. Things such as the STL library would use extra checks to see you are accessing invalid iterators, the heap would have extra checking code for bad pointer access and corruption, etc.

Regards,

Paul McKenzie

Quote:

---

Originally Posted by pocruadhlaoich

My goal though is to create a "Release with debug information" build, so if you have a release build that has been set to disable optimisations, then is it really a release build?

---

It is a build with optimizations disabled. That's all it is.

If your program does indeed behave differently if optimizations are used, then you have a greater problem than just what a typical debugging session will reveal. You would have to go beyond the source level and see the underlying generated assembly code to see what is happening.

Regards,

Paul McKenzie

Ahhh I see! Thanks very much for your help!

Wow, I hate to say it, but most of you guys seem to have no idea what you're talking about. The OP's question is perfectly sensible and easily answered: copy the release profile ("RelSym" or "RelWithDebInfo" are common names) and change one value in the project. In the project's General tab, change Debugging information to "Program Database /Zi". Ta-da, done.

In the project file, it changes DebugInformationFormat from 0 to 3.

This doesn't generate a _DEBUG build, disable optimization, or anything else you guys are talking about. It only lets you more easily debug a fully optimized release build (if not as easily as with a real Debug build). You really need to get with the times or learn your craft, this has been available since the early 90's. It's a long-cherished best practice to keep symbols of EVERY public release so that you can debug crash dumps, too.