Problems debugging with Windbg using a debug graphics device driver compiled with WinDDK 3790.1830 + ICL 11.1.048

[Holly_P_Intel]

Hi,

I am trying to build a Windows XP graphics device driver using ICL + WinDDK 3790.1830 for an Atom-based platform.

I was successful in building a release driver by adding ICL libraries and compiler flags in the WinDDKs i386mk.inc file:

# comment DBGFLAGS for debug build, the MSC_OPTIMIZATION flag (/Od /Oi) causes compilation errors in debug build.
#DBGFLAGS=$(DBGFLAGS) $(MSC_OPTIMIZATION) $(LINK_TIME_CODE_GENERATION_MSC_FLAG)

. . .

SUBSTITUTE_386_CC = 1# set to 1 to compile with ICL
!if "$(SUBSTITUTE_386_CC)" != ""
STDFLAGS = $(STDFLAGS) /QxSSE3_ATOM # add atom optimization flag
TARGETLIBS = $(TARGETLIBS) \\
C:/Progra~1/Intel/Compiler/11.1/048/lib/ia32/libirc.lib \\ # add ICL libraries
C:/Progra~1/Intel/Compiler/11.1/048/lib/ia32/libm.lib \\
C:/Progra~1/Intel/Compiler/11.1/048/lib/ia32/svml_disp.lib
CC_NAME = "$(ICPP_COMPILER11)bin\\ia32\\icl.exe" -nologo # compile with icl.exe
!else
! if defined(RAZZLETOOLPATH) && !defined( PREFAST_ADD_PATH )
CC_NAME = $(RAZZLETOOLPATH)\\x86\\cl -nologo
! else
CC_NAME=cl -nologo
! endif
CC_NAME=cl -nologo
!endif
. . .

This configuration also compiles the debug driver successfully. However, the debug driver does not get loaded properly on the target system.

After some experimentation, I found that adding /Qip resolves the loading issue:

STDFLAGS = $(STDFLAGS) /QxSSE3_ATOM /Qip

And I dont have any problem attaching Windbg and setting breakpoints. The only remaining issue I am encountering is when a breakpoint gets hit, the instruction pointer (continuously pressing F10) does not flow in a linear fashion; instead it jumps to different lines of code. Also, the data of local variables is garbage. I believe the reason for this is the code is optimized by the Intel compiler.

I tried disabling all optimizations by adding such flags as /Zi /Z7 /O0:

STDFLAGS = $(STDFLAGS) /Zi /Z7 /O0

But I would get compilation errors:

1>c:\\\\main\\\\main.lib(main.obj) : error LNK2001: unresolved external symbol _memcmp
1>c:\\\\main\\\\libm.lib(libm_error.obj) : error LNK2019: unresolved external symbol __iob referenced in function _write_message
1>c:\\\\main\\\\libm.lib(libm_error.obj) : error LNK2019: unresolved external symbol __imp__FormatMessageA@28 referenced in function _write_message
1>c:\\\\main\\\\libm.lib(libm_error.obj) : error LNK2019: unresolved external symbol _fputs referenced in function _write_message
1>c:\\\\main\\\\libm.lib(libm_error.obj) : error LNK2019: unresolved external symbol __imp__GetThreadLocale@0 referenced in function _write_message
1>c:\\\\main\\\\libm.lib(libm_error.obj) : error LNK2019: unresolved external symbol __imp__LoadLibraryA@4 referenced in function _write_message
1>c:\\\\main\\\\libm.lib(libm_error.obj) : error LNK2019: unresolved external symbol _errno referenced in function ___libm_error_support

I am quickly running out of ideas.

Has anyone had any success building a debug driver with ICL + WinDDK 3790.1830 and was able to debug using Windbg with no issues?

Thanks for your help in advance.

-Holly

[TimP]

/O0 doesn't have a meaning on Windows; maybe you meant /Od.

Are you mixing stdcall or Compaq Fortran linking conventions of 9 years ago with current cdecl? You must stick with one of them. I would hesitate to count on the obsolete convention having been tested sufficiently with the atom option.

[Dale_S_Intel]

Quoting Holly Pang (Intel)

And I dont have any problem attaching Windbg and setting breakpoints. The only remaining issue I am encountering is when a breakpoint gets hit, the instruction pointer (continuously pressing F10) does not flow in a linear fashion; instead it jumps to different lines of code. Also, the data of local variables is garbage. I believe the reason for this is the code is optimized by the Intel compiler.

I tried disabling all optimizations by adding such flags as /Zi /Z7 /O0:

STDFLAGS = $(STDFLAGS) /Zi /Z7 /O0

Not sure about the compilation errors, but as Tim points out, you probably want /Od. The behavior your describing in the debuger is consistent with optimized code, so you'll want to turn off optimizations with /Od.

Dale

[Holly_P_Intel]

Hi Dale & Tim,

Thank you both for your input. I am using cdecl (/Gd) and not stdcall.

Here isthe build command:

1>BUILD: Compile and Link for i386
1>"C:\\Program Files\\Intel\\Compiler\\11.1\\048\\bin\\ia32\\icl.exe" -nologo -Ii386\\ -I.
-IC:\\WINDDK\\3790~1.183\\inc\\mfc42
-IC:/main
-IC:\\WINDDK\\3790~1.183\\inc\\ddk\\wxp
-IC:\\WINDDK\\3790~1.183\\inc\\ddk\\wdm\\wxp
-IC:\\WINDDK\\3790~1.183\\inc\\crt
-IC:\\WINDDK\\3790~1.183\\inc\\wxp
-IC:\\WINDDK\\3790~1.183\\inc\\wxp
-IC:\\WINDDK\\3790~1.183\\inc\\crt
D_X86_=1 -Di386=1 -DCONDITION_HANDLING=1 -DNT_INST=0 -DWIN32=100 -D_NT1X_=100 -DWINNT=1 -D_WIN32_WINNT=0x0501 /DWINVER=0x0501 -D_WIN32_IE=0x0603 -DWIN32_LEAN_AND_MEAN=1 -DDEVL=1 -DDBG=1 -D__BUILDMACHINE__=WinDDK -DFPO=0 -DNDEBUG
/c /Zp8 /W3 /WX /Gd /GX- /GR- /GS /Ze /Gi- /hotpatch
/QxSSE3_ATOM /Qip /Z7 /Zi /Oy- /QIfist # these are the ICL options that I added
-FIC:\WINDDK\3790~1.183\inc\wxp\warning.h

I removed all the ICL flags that I added, which are "/QxSSE3_ATOM /Qip /Z7 /Zi" and replaced these with just "/Od" and got the same compilation errors as shown in my original post.

Then I removed all of these flags and tried building, but still got the same compilation errors.

At a minimal, it looks like "/QxSSE3_ATOM" must be added toresolved all the compilation errors. I am beginning to wonder whether if this is the root of the issue, since this flag does generate optimized code.

Thanks,
Holly