none
Change compiler options for better debugging RRS feed

  • Question

  • Brian and others:

     I get "Memory access error" when debugging some piece of code in WRK v1.2. I guess it would be better to disable compiler's optimization options?

     In the "makefile.build", line 15 is,

    targcopts = -Gm- -Gz -GX- -G6 -Ze -Gi- -QIfdiv- -Z7 -Oxs -Oy-

     and I change it to be,

    targcopts = -Gm- -Gz -GX- -G6 -Ze -Gi- -QIfdiv- -Z7 -Odi -Oy-

    I rebuild and replace the kernel. After the windows server 2003 logo screen, it shows a blue screen, in seconds it restart. In that short time, the information I can notice include "c0000218", registry file failed, and ...\SAM (some registry path)

     This is my second try. I did encounter a problem at the first try. It stopped when shutting down after I replaced the kernel. I restarted the virtual machine. It is possible registry was corrupted at that time. However, I can use the original 2003 kernel and WRK kernel built from the origin compiler options to start the virtual machine.

     I need some guidance to solve the problem. Thanks for any information.

     

    Yu-ning

    Thursday, March 22, 2007 7:26 AM

Answers

  • Within the kernel team we are generally debugging systems running retail builds, so all the debugging tools are oriented towards working well with the optimizations turned on.  The main issue you may find distracting is that stepping through assembly code can be a little confusing because code blocks are moved around some. 

    In other words, there isn't much to be gained by turning off optimizations.  But figuring out what optimizations you can turn off to just recompile the WRK without recompiling the hal, key drivers, ntdll, kernel32, and other components is not straightforward -- so there is a lot to be lost.  So that's why I recommend just leaving optimizations enabled when debugging.

    Monday, April 2, 2007 8:32 PM

All replies

  • No, don’t change the optimizations.  It doesn’t affect debugging that much and (apparently) does break the kernel.

     

    Do you have a stacktrace and registers for the original memory error you were debugging?

     

    Was the information on kernel debugging in the Debugger help system helpful?

    Thursday, March 22, 2007 4:48 PM
  • Thanks for your information.

    I used to think that disabling optimizations is better...
    So compiling kernel is different.
    Could you explain more, Dave?

    I have not tried those yet. I will do it and report back ASAP.
    Friday, March 23, 2007 2:40 AM
  • Within the kernel team we are generally debugging systems running retail builds, so all the debugging tools are oriented towards working well with the optimizations turned on.  The main issue you may find distracting is that stepping through assembly code can be a little confusing because code blocks are moved around some. 

    In other words, there isn't much to be gained by turning off optimizations.  But figuring out what optimizations you can turn off to just recompile the WRK without recompiling the hal, key drivers, ntdll, kernel32, and other components is not straightforward -- so there is a lot to be lost.  So that's why I recommend just leaving optimizations enabled when debugging.

    Monday, April 2, 2007 8:32 PM
  • Many thanks, Dave. I feel lucky to get help from you.

    Yes, you pointed out the thing I encountered. I needed to compare the disassembly and the c code to find out the values of some variables. Seems after opt, some variables did not present as a memory unit but registers, and sometimes instruction order is changed. ( I almost forgot that knowledge learnt in compiler and architecture courses ).

    I do not work on that piece of code these days. However, I am in similar situation on the code I am working on. By practising
    more with WinDbg, reading registers, disassembly and source, I get the information I need. I think I am a better debugger user now.

    Sorry for reporting late.

    Good luck to all reading code and debugging.


    Yu-ning

    Thursday, April 5, 2007 3:13 AM