I don’t think it is a C/C++ issue, but it would be really useful to see the
definition of CORE_DAL_VERIFY. One of the problems with macros is that they
are textual substitutions, and it is far too easy to create a macro that
evaluates its arguments more than once. May macros assume that their
operands are effectively const. So showing the definition of this macro
would be a big help.
The problem here is that you are apparently trusting your “intuition” about
the macro without actually seeing what code was actually generated. A first
step in this process would be to compile with the /P (case-sensitive, so not
/p) switch to the compiler. Then examine the resulting .i file that is
produced to see what code the macro generated; if you see two calls on
Core_AddContainerToWorkLoop in the .i file, that would explain what is
happening here.
Note that if you compile with /P, it does not actually compile the file, it
just runs it through the preprocessor and generates a .i file. This file
will contain a lot of fluff from the inclusion of tons of header files, and
all comments will have been removed, making it somewhat challenging to
locate the actual code, but until you have done this step, there is no way
to tell what is happening, really. You are merely assuming that because you
wrote the function call once in the source, that it appears only once in
what the compiler sees.
After you have done this step, and shown what the code is at that line in
the compiler input, then we can investigate what really happened.
joe
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of J. J. Farrell
Sent: Sunday, March 06, 2011 8:34 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] C(pp) code and assembly code mismatch.
It’s very hard to say why source code has been concerted to a particular
object code sequence without seeing the source code and knowing whether it
is C or C++.
xxxxx@hotmail.com wrote:
I’m using compiler : BUILD: Version 6.1.7063.0.
Below is the result COD file from the source. What I am curious is that
the assembly calls _Core_AddContainerToWorkLoop@8 routine 2 times versus
the C code is one time.
I don’t know what cause this problem. So when I execute the driver it
calls the routine 2 times.
Thanks,
; 2034 :
; 2035 : CORE_DAL_VERIFY(
; 2036 : Core_AddContainerToWorkLoop( npa.npa_event_queue_handle,
npa.npa_event_handle ) );
000d7 8b 15 98 00 00
00 mov edx, DWORD PTR _npa+152
000dd 52 push edx
000de a1 9c 00 00 00 mov eax, DWORD PTR _npa+156
000e3 50 push eax
000e4 e8 00 00 00 00 call _Core_AddContainerToWorkLoop@8
000e9 f7 d8 neg eax
000eb 1b c0 sbb eax, eax
000ed 83 c0 01 add eax, 1
000f0 50 push eax
000f1 68 00 00 00 00 push OFFSET
??xxxxx@xxxxx@xxxxx@CORE_VERIFY?5X?$CI?$CFd?$CJ?5Result?$AN?6?$xxxxx@FNODOBFM@
000f6 6a 03 push 3
000f8 6a 65 push 101 ; 00000065H
000fa ff 15 00 00 00
00 call DWORD PTR __imp__DbgPrintEx
00100 83 c4 10 add esp, 16 ;
00000010H
00103 8b 0d 98 00 00
00 mov ecx, DWORD PTR _npa+152
00109 51 push ecx
0010a 8b 15 9c 00 00
00 mov edx, DWORD PTR _npa+156
00110 52 push edx
00111 e8 00 00 00 00 call _Core_AddContainerToWorkLoop@8
00116 f7 d8 neg eax
00118 1b c0 sbb eax, eax
0011a 83 c0 01 add eax, 1
0011d 75 01 jne SHORT $xxxxx@npa_init_w
0011f cc int 3
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
–
This message has been scanned for viruses and dangerous content by
MailScanner, and is believed to be clean.