Putting debug info in executable
-
Before we upgraded to Visual C/C++ 7.1, we used version 6.0 of the compiler. To make it easier for us and our help desk to find problems, we linked our production (release) versions with /DEBUG and /PDB:NONE (but all sources were compiled with /Ox and no debug info). That way information about the addresses of functions and methods were stored in the executable, ready for Dr.Watson to read them. This also had the advantage that we could use SymGetSymFromAddr to get the symbol name (of a function) for a function address (handy if you e.g. want to report the stack at the moment of a memory leak). Unfortunately Visual C/C++ does not have the option /PDB:NONE anymore, which means we cannot put this information int he executable anymore (and our nice feature of printing out the stack when a memory leak was found does not work anymore either). AAAAAAAAAAAArgh. Is there another way of storing the function addresses so this info can be read by Dr.Watson and still works with SymGetSymFromAddr (the first one is more urgent), using Visual C/C++ 7.1? Otherwise we have to read stuff like this:
FramePtr ReturnAd Param#1 Param#2 Param#3 Param#4 Function Name 0012F054 00549EBF 01BA91A8 00000001 006AE5E0 0012F0CC !<nosymbols> 0012F104 00508DCA 009DDDB0 00000000 00000001 0057A490 !<nosymbols> 0012F120 0057A43C 009DDDB0 00000001 0057A490 0012F148 !<nosymbols> 0012F1D0 0046F330 01570F58 02DB9118 00000000 00030018 !<nosymbols> 0012F29C 0048F9FC 02D88BD8 0012F70C 00000000 01C3C4C0 !<nosymbols>and map each pointer (probably ReturnAddress) to something similar in the .map file (created with the /MAP option). This is horrible and time consuming. Somebody who knows a solution? Enjoy life, this is not a rehearsal !!! My Articles: - Implementing a Subject/Observer pattern with templates - Different ways of writing class factories - AutoRunner: a template class to automatically run start- and cleanup-code in code blocks -
Before we upgraded to Visual C/C++ 7.1, we used version 6.0 of the compiler. To make it easier for us and our help desk to find problems, we linked our production (release) versions with /DEBUG and /PDB:NONE (but all sources were compiled with /Ox and no debug info). That way information about the addresses of functions and methods were stored in the executable, ready for Dr.Watson to read them. This also had the advantage that we could use SymGetSymFromAddr to get the symbol name (of a function) for a function address (handy if you e.g. want to report the stack at the moment of a memory leak). Unfortunately Visual C/C++ does not have the option /PDB:NONE anymore, which means we cannot put this information int he executable anymore (and our nice feature of printing out the stack when a memory leak was found does not work anymore either). AAAAAAAAAAAArgh. Is there another way of storing the function addresses so this info can be read by Dr.Watson and still works with SymGetSymFromAddr (the first one is more urgent), using Visual C/C++ 7.1? Otherwise we have to read stuff like this:
FramePtr ReturnAd Param#1 Param#2 Param#3 Param#4 Function Name 0012F054 00549EBF 01BA91A8 00000001 006AE5E0 0012F0CC !<nosymbols> 0012F104 00508DCA 009DDDB0 00000000 00000001 0057A490 !<nosymbols> 0012F120 0057A43C 009DDDB0 00000001 0057A490 0012F148 !<nosymbols> 0012F1D0 0046F330 01570F58 02DB9118 00000000 00030018 !<nosymbols> 0012F29C 0048F9FC 02D88BD8 0012F70C 00000000 01C3C4C0 !<nosymbols>and map each pointer (probably ReturnAddress) to something similar in the .map file (created with the /MAP option). This is horrible and time consuming. Somebody who knows a solution? Enjoy life, this is not a rehearsal !!! My Articles: - Implementing a Subject/Observer pattern with templates - Different ways of writing class factories - AutoRunner: a template class to automatically run start- and cleanup-code in code blocksWouldn't it be easier to just fix the app so that it doesn't crash anymore? onwards and upwards...
-
Wouldn't it be easier to just fix the app so that it doesn't crash anymore? onwards and upwards...
That's pretty crass. It sounds like you work in a world of software that lives in an extremely controlled environment. Well, good for you. The rest of us make do in a world of windows with spyware, third-party audio drivers, third-party video drivers, third-party camera drivers, different flavors of windows with different behaviors, and on and on -- things that cause the environment to become less than standard and less than well perfectly behaved. Things do crash. And if you're not prepared to support your customers with crash support and diagnosis, then good luck. This place is all about help and support -- sharing knowledge not attitude. I don't know the answer to his question, but I do know that your response to him doesn't help (and for that matter, neither does mine). I, too, am interested in this topic, as this behavior affects our products as well Thank you very much. That's all I have to say.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Peter Weyzen Staff Engineer [Santa Cruz Networks](http://www.santacruznetworks.com) -
Before we upgraded to Visual C/C++ 7.1, we used version 6.0 of the compiler. To make it easier for us and our help desk to find problems, we linked our production (release) versions with /DEBUG and /PDB:NONE (but all sources were compiled with /Ox and no debug info). That way information about the addresses of functions and methods were stored in the executable, ready for Dr.Watson to read them. This also had the advantage that we could use SymGetSymFromAddr to get the symbol name (of a function) for a function address (handy if you e.g. want to report the stack at the moment of a memory leak). Unfortunately Visual C/C++ does not have the option /PDB:NONE anymore, which means we cannot put this information int he executable anymore (and our nice feature of printing out the stack when a memory leak was found does not work anymore either). AAAAAAAAAAAArgh. Is there another way of storing the function addresses so this info can be read by Dr.Watson and still works with SymGetSymFromAddr (the first one is more urgent), using Visual C/C++ 7.1? Otherwise we have to read stuff like this:
FramePtr ReturnAd Param#1 Param#2 Param#3 Param#4 Function Name 0012F054 00549EBF 01BA91A8 00000001 006AE5E0 0012F0CC !<nosymbols> 0012F104 00508DCA 009DDDB0 00000000 00000001 0057A490 !<nosymbols> 0012F120 0057A43C 009DDDB0 00000001 0057A490 0012F148 !<nosymbols> 0012F1D0 0046F330 01570F58 02DB9118 00000000 00030018 !<nosymbols> 0012F29C 0048F9FC 02D88BD8 0012F70C 00000000 01C3C4C0 !<nosymbols>and map each pointer (probably ReturnAddress) to something similar in the .map file (created with the /MAP option). This is horrible and time consuming. Somebody who knows a solution? Enjoy life, this is not a rehearsal !!! My Articles: - Implementing a Subject/Observer pattern with templates - Different ways of writing class factories - AutoRunner: a template class to automatically run start- and cleanup-code in code blocksYou have probably done this but MSDN suggests that instead of /PDB:NONE you use /Zi. From the description it sounds like they do the same thing.:confused: // Afterall, I realized that even my comment lines have bugs When one cannot invent, one must at least improve (in bed).-My latest fortune cookie