OSR's ntdev List: Bug with InterlockedExchange() or possibly compiler?

Message 1 of 14

18 May 06 13:21

Charlie Suffin

xxxxxx@egenera.com

Join Date: 18 May 2006

Posts To This List: 9

Bug with InterlockedExchange() or possibly compiler?

In the code listing snippet below, I think the code generated for line 3327 is incorrect. I'm wondering if this problem has been reported before to NTDEV and how widespread this might be. I tried a few NTDEV searches but didn't find anything. If you folks concur, I will report this to MS. Specifically, at offset 00dea below, the compiler is assuming that the state of the ZF flag reflects whether or not the prevState value is zero; in fact, the ZF flag is holding the result from the cmpxchg instruction, and thus the jne is never taken. This code behaves as if prevState is always zero! ; 3325 : ULONG prevState; ; 3326 : prevState = InterlockedOr(&pCmdBlock->State, 0x4); 00dcc ba 04 00 00 00 mov edx, 4 00dd1 8b 45 0c mov eax, DWORD PTR _pCmdBlock$[ebp] 00dd4 83 c0 28 add eax, 40 ; 00000028H 00dd7 8b c8 mov ecx, eax 00dd9 8b 01 mov eax, DWORD PTR [ecx] $L30114: 00ddb 8b f0 mov esi, eax 00ddd 0b f2 or esi, edx 00ddf f0 0f b1 31 lock cmpxchg DWORD PTR [ecx], esi 00de3 75 f6 jne SHORT $L30114 00de5 8b d0 mov edx, eax 00de7 89 55 cc mov DWORD PTR _prevState$29001[ebp], edx ; 3327 : if (prevState == 0) 00dea 75 0d jne SHORT $L28874 ; 3328 : { ; 3329 : KdPrint(("HUH!\n")); 00dec 68 00 00 00 00 push OFFSET FLAT:$SG29003 00df1 e8 00 00 00 00 call _DbgPrint 00df6 83 c4 04 add esp, 4 $L28874: I have played around a bit with this code. If I test prevState against some value other than zero, the compiler emits a cmp instruction before the jne (and it's correct). The problem seems to be limited to == or != zero. This code was compiled for a checked x86 build with the 3790.1830 DDK. What do you think? -- Charlie

Message 2 of 14

18 May 06 14:07

Tony Mason

xxxxxx@osr.com

Join Date:

Posts To This List: 299

List Moderator

RE: Bug with InterlockedExchange() or possibly compiler?

I did go so far as to confirm that the MOV operations previous don't have any side effect (they don't set any flags, in fact.) Thus, your initial analysis (that this is testing the wrong result) seems plausible. I have never used, nor ever seen the InterlockedOr operation used. According to the header file I checked (w2k3) it is a compiler intrinsic - so if you see that the code generated is different with a value OTHER THAN zero, I'd definitely report it to the DDK team (keep in mind that the DDK uses the OS-version of the compiler for this work.) Compiler bugs, while exceedingly rare, do occur and you seem to have done at least the first-level analysis to confirm that this is what's happening here. Time to report this to someone who can confirm/refute and go from there. Regards, Tony Tony Mason Consulting Partner OSR Open Systems Resources, Inc. http://www.osr.com -----Original Message----- From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Suffin, Charlie Sent: Thursday, May 18, 2006 1:21 PM To: ntdev redirect Subject: [ntdev] Bug with InterlockedExchange() or possibly compiler? In the code listing snippet below, I think the code generated for line 3327 is incorrect. I'm wondering if this problem has been reported before to NTDEV and how widespread this might be. I tried a few NTDEV searches but didn't find anything. If you folks concur, I will report this to MS. Specifically, at offset 00dea below, the compiler is assuming that the state of the ZF flag reflects whether or not the prevState value is zero; in fact, the ZF flag is holding the result from the cmpxchg instruction, and thus the jne is never taken. This code behaves as if prevState is always zero! ; 3325 : ULONG prevState; ; 3326 : prevState = InterlockedOr(&pCmdBlock->State, 0x4); 00dcc ba 04 00 00 00 mov edx, 4 00dd1 8b 45 0c mov eax, DWORD PTR _pCmdBlock$[ebp] 00dd4 83 c0 28 add eax, 40 ; 00000028H 00dd7 8b c8 mov ecx, eax 00dd9 8b 01 mov eax, DWORD PTR [ecx] $L30114: 00ddb 8b f0 mov esi, eax 00ddd 0b f2 or esi, edx 00ddf f0 0f b1 31 lock cmpxchg DWORD PTR [ecx], esi 00de3 75 f6 jne SHORT $L30114 00de5 8b d0 mov edx, eax 00de7 89 55 cc mov DWORD PTR _prevState$29001[ebp], edx ; 3327 : if (prevState == 0) 00dea 75 0d jne SHORT $L28874 ; 3328 : { ; 3329 : KdPrint(("HUH!\n")); 00dec 68 00 00 00 00 push OFFSET FLAT:$SG29003 00df1 e8 00 00 00 00 call _DbgPrint 00df6 83 c4 04 add esp, 4 $L28874: I have played around a bit with this code. If I test prevState against some value other than zero, the compiler emits a cmp instruction before the jne (and it's correct). The problem seems to be limited to == or != zero. This code was compiled for a checked x86 build with the 3790.1830 DDK. What do you think? -- Charlie --- Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Message 3 of 14

18 May 06 14:45

Charlie Suffin

xxxxxx@egenera.com

Join Date: 18 May 2006

Posts To This List: 9

RE: Bug with InterlockedExchange() or possibly compiler?

Thank you for your inspection of this, Tony. Indeed, I spent some time convincing myself that either the DDK includes or the compiler is at fault since (as you say) this is rare. OK, I've reported this problem through the MSDN Product Feedback Center. FYI, it's now listed as Bug ID: FDBK50137. There was no "DDK" product to report it against, so I reported it under "Visual C++." I hope this problem is not exposed in other implementations of the InterlockedXxxx() DDK calls, etc. I will post if there is any change of status. -- Charlie -----Original Message----- From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Tony Mason Sent: Thursday, May 18, 2006 2:05 PM To: Windows System Software Devs Interest List Subject: RE: [ntdev] Bug with InterlockedExchange() or possibly compiler? I did go so far as to confirm that the MOV operations previous don't have any side effect (they don't set any flags, in fact.) Thus, your initial analysis (that this is testing the wrong result) seems plausible. I have never used, nor ever seen the InterlockedOr operation used. According to the header file I checked (w2k3) it is a compiler intrinsic - so if you see that the code generated is different with a value OTHER THAN zero, I'd definitely report it to the DDK team (keep in mind that the DDK uses the OS-version of the compiler for this work.) Compiler bugs, while exceedingly rare, do occur and you seem to have done at least the first-level analysis to confirm that this is what's happening here. Time to report this to someone who can confirm/refute and go from there. Regards, Tony Tony Mason Consulting Partner OSR Open Systems Resources, Inc. http://www.osr.com -----Original Message----- From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Suffin, Charlie Sent: Thursday, May 18, 2006 1:21 PM To: ntdev redirect Subject: [ntdev] Bug with InterlockedExchange() or possibly compiler? In the code listing snippet below, I think the code generated for line 3327 is incorrect. I'm wondering if this problem has been reported before to NTDEV and how widespread this might be. I tried a few NTDEV searches but didn't find anything. If you folks concur, I will report this to MS. Specifically, at offset 00dea below, the compiler is assuming that the state of the ZF flag reflects whether or not the prevState value is zero; in fact, the ZF flag is holding the result from the cmpxchg instruction, and thus the jne is never taken. This code behaves as if prevState is always zero! ; 3325 : ULONG prevState; ; 3326 : prevState = InterlockedOr(&pCmdBlock->State, 0x4); 00dcc ba 04 00 00 00 mov edx, 4 00dd1 8b 45 0c mov eax, DWORD PTR _pCmdBlock$[ebp] 00dd4 83 c0 28 add eax, 40 ; 00000028H 00dd7 8b c8 mov ecx, eax 00dd9 8b 01 mov eax, DWORD PTR [ecx] $L30114: 00ddb 8b f0 mov esi, eax 00ddd 0b f2 or esi, edx 00ddf f0 0f b1 31 lock cmpxchg DWORD PTR [ecx], esi 00de3 75 f6 jne SHORT $L30114 00de5 8b d0 mov edx, eax 00de7 89 55 cc mov DWORD PTR _prevState$29001[ebp], edx ; 3327 : if (prevState == 0) 00dea 75 0d jne SHORT $L28874 ; 3328 : { ; 3329 : KdPrint(("HUH!\n")); 00dec 68 00 00 00 00 push OFFSET FLAT:$SG29003 00df1 e8 00 00 00 00 call _DbgPrint 00df6 83 c4 04 add esp, 4 $L28874: I have played around a bit with this code. If I test prevState against some value other than zero, the compiler emits a cmp instruction before the jne (and it's correct). The problem seems to be limited to == or != zero. This code was compiled for a checked x86 build with the 3790.1830 DDK. What do you think? -- Charlie --- Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer --- Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Message 4 of 14

18 May 06 15:04

ntdev member 2092

xxxxxx@stratus.com

Join Date:

Posts To This List: 1798

RE: Bug with InterlockedExchange() or possibly compiler?

Charlie, Did I ever mention that I hate assembler? So after hurting myself with the definition of cmpxchg I think that the jne is taken repeatedly until pCmdBlock->State has not been modified between the instruction at 0dd7 and the cmpxchg at ddf. The intrinsic is spinning in order to keeps its interlocked or contract, nothing more. -----Original Message----- From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Suffin, Charlie Sent: Thursday, May 18, 2006 1:21 PM To: Windows System Software Devs Interest List Subject: [ntdev] Bug with InterlockedExchange() or possibly compiler? In the code listing snippet below, I think the code generated for line 3327 is incorrect. I'm wondering if this problem has been reported before to NTDEV and how widespread this might be. I tried a few NTDEV searches but didn't find anything. If you folks concur, I will report this to MS. Specifically, at offset 00dea below, the compiler is assuming that the state of the ZF flag reflects whether or not the prevState value is zero; in fact, the ZF flag is holding the result from the cmpxchg instruction, and thus the jne is never taken. This code behaves as if prevState is always zero! ; 3325 : ULONG prevState; ; 3326 : prevState = InterlockedOr(&pCmdBlock->State, 0x4); 00dcc ba 04 00 00 00 mov edx, 4 00dd1 8b 45 0c mov eax, DWORD PTR _pCmdBlock$[ebp] 00dd4 83 c0 28 add eax, 40 ; 00000028H 00dd7 8b c8 mov ecx, eax 00dd9 8b 01 mov eax, DWORD PTR [ecx] $L30114: 00ddb 8b f0 mov esi, eax 00ddd 0b f2 or esi, edx 00ddf f0 0f b1 31 lock cmpxchg DWORD PTR [ecx], esi 00de3 75 f6 jne SHORT $L30114 00de5 8b d0 mov edx, eax 00de7 89 55 cc mov DWORD PTR _prevState$29001[ebp], edx ; 3327 : if (prevState == 0) 00dea 75 0d jne SHORT $L28874 ; 3328 : { ; 3329 : KdPrint(("HUH!\n")); 00dec 68 00 00 00 00 push OFFSET FLAT:$SG29003 00df1 e8 00 00 00 00 call _DbgPrint 00df6 83 c4 04 add esp, 4 $L28874: I have played around a bit with this code. If I test prevState against some value other than zero, the compiler emits a cmp instruction before the jne (and it's correct). The problem seems to be limited to == or != zero. This code was compiled for a checked x86 build with the 3790.1830 DDK. What do you think? -- Charlie --- Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Message 5 of 14

18 May 06 18:38

don ward

xxxxxx@careful.co.uk

Join Date: 03 Dec 2004

Posts To This List: 107

RE: Bug with InterlockedExchange() or possibly compiler?

I fell over this this bug a few years ago. I should have reported it, but didn't (mea Culpa). A workaround is to insert a function call that cannot be optimised away between the interlockedOr and the test. Here is an extract from my code that explains things // NB.NB.NB.NB.NB.NB.NB.NB.NB.NB.NB.NB.NB.NB.NB.NB.NB.NB.NB.NB.NB.NB.NB.NB.NB.NB.NB. // Compiler Bug (!) // [DPW] The following code sequence demonstrates a problem in the Server2003 DDK C compiler // x = InterlockedAnd(&y,0); /* Point A */ // if (x == 0) /* Point B */ // { /* This branch is always taken, no matter what the value of x is */ // ASSERT(x == 0); /* <--- The assert fails when y != 0 */ // } // else // { // /* This branch is never taken, no matter what the value of x is */ // } // The register tracking logic loses the plot on what values are in what registers and lays down incorrect code. // Putting a function call that cannot be optimised away between point A and point B solves the problem // because the compiler can no longer assume it knows the register contents after the InterlockedAnd, // so it emits code that tests the value of x correctly. // //NB.NB.NB.NB.NB.NB.NB.NB.NB.NB.NB.NB.NB.NB.NB.NB.NB.NB.NB.NB.NB.NB.NB.NB.NB.NB.N B.NB. cancelledLocks = InterlockedAnd(&Ext->userInfo.cancelledLocks, 0); /* Read and clear */ kpdDummy(Ext); /* [DPW] DO NOT REMOVE THIS FUNCTION CALL, EVER. */ if (cancelledLocks == 0) In my case, kpdDummy makes a harmless "change" to my device extension and it's in a separate compilation unit. In theory the global optimiser could figure out that it could be elided but, if it ever happened, I'd be amazed. And, if the compiler is smart enough to do that it's smart enough to get the register tracking logic right. Regards Don > -----Original Message----- > From: xxxxx@lists.osr.com > [mailto:xxxxx@lists.osr.com] On Behalf Of > Suffin, Charlie > Sent: 18 May 2006 18:21 > To: Windows System Software Devs Interest List > Subject: [ntdev] Bug with InterlockedExchange() or possibly compiler? > > > In the code listing snippet below, I think the code generated for line <...excess quoted lines suppressed...>

Message 6 of 14

18 May 06 19:30

Charlie Suffin

xxxxxx@egenera.com

Join Date: 18 May 2006

Posts To This List: 9

RE: Bug with InterlockedExchange() or possibly compiler?

Don, Looks like you hit the same thing, although apparently you saw it under InterlockedAnd(). Mine was under InterlockedOr()... That's a little scary. This could be lurking in other InterlockedXxxx() functions, and perhaps I should check our code base for all occurrences. Your comments about the register tracking logic and optimization in the compiler... Do you know this for a fact, or is this your assumption? If you're sure, I'll add your comments to my MS bug report to maybe help them evaluate the bug. The reason I ask is that I'm building for checked x86 here; I actually wouldn't expect much optimization to be done by the compiler -- but I don't really know. Anyway, thanks! Oh, by the way, my compilation is under Visual Studio 2003's C compiler. I wonder if 2005 has maybe fixed this problem (I didn't try that)... -- Charlie

Message 7 of 14

18 May 06 19:44

ntdev member 8437

xxxxxx@windows.microsoft.com

Join Date:

Posts To This List: 1404

RE: Bug with InterlockedExchange() or possibly compiler?

What compiler version is this in? -p -----Original Message----- From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Don Ward Sent: Thursday, May 18, 2006 3:32 PM To: Windows System Software Devs Interest List Subject: RE: [ntdev] Bug with InterlockedExchange() or possibly compiler? I fell over this this bug a few years ago. I should have reported it, but didn't (mea Culpa). A workaround is to insert a function call that cannot be optimised away between the interlockedOr and the test. Here is an extract from my code that explains things // NB.NB.NB.NB.NB.NB.NB.NB.NB.NB.NB.NB.NB.NB.NB.NB.NB.NB.NB.NB.NB.NB.NB.NB. NB.NB.NB. // Compiler Bug (!) // [DPW] The following code sequence demonstrates a problem in the Server2003 DDK C compiler // x = InterlockedAnd(&y,0); /* Point A */ // if (x == 0) /* Point B */ // { /* This branch is always taken, no matter what the value of x is */ // ASSERT(x == 0); /* <--- The assert fails when y != 0 */ // } // else // { // /* This branch is never taken, no matter what the value of x is */ // } // The register tracking logic loses the plot on what values are in what registers and lays down incorrect code. // Putting a function call that cannot be optimised away between point A and point B solves the problem // because the compiler can no longer assume it knows the register contents after the InterlockedAnd, // so it emits code that tests the value of x correctly. // //NB.NB.NB.NB.NB.NB.NB.NB.NB.NB.NB.NB.NB.NB.NB.NB.NB.NB.NB.NB.NB.NB.NB.N B.NB.NB.NB.NB. cancelledLocks = InterlockedAnd(&Ext->userInfo.cancelledLocks, 0); /* Read and clear */ kpdDummy(Ext); /* [DPW] DO NOT REMOVE THIS FUNCTION CALL, EVER. */ if (cancelledLocks == 0) In my case, kpdDummy makes a harmless "change" to my device extension and it's in a separate compilation unit. In theory the global optimiser could figure out that it could be elided but, if it ever happened, I'd be amazed. And, if the compiler is smart enough to do that it's smart enough to get the register tracking logic right. Regards Don > -----Original Message----- > From: xxxxx@lists.osr.com > [mailto:xxxxx@lists.osr.com] On Behalf Of Suffin, > Charlie > Sent: 18 May 2006 18:21 > To: Windows System Software Devs Interest List > Subject: [ntdev] Bug with InterlockedExchange() or possibly compiler? > > > In the code listing snippet below, I think the code generated for line <...excess quoted lines suppressed...> --- Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Message 8 of 14

18 May 06 19:58

Charlie Suffin

xxxxxx@egenera.com

Join Date: 18 May 2006

Posts To This List: 9

RE: Bug with InterlockedExchange() or possibly compiler?

Peter, I'm building this driver on my XP laptop, but it's the Windows 2003 SP1 DDK with Visual 2003 cl compiler. The code listing says this: ; Listing generated by Microsoft (R) Optimizing Compiler Version 13.10.4035 Hope that helps... -- Charlie

Message 9 of 14

18 May 06 19:59

don ward

xxxxxx@careful.co.uk

Join Date: 03 Dec 2004

Posts To This List: 107

RE: Bug with InterlockedExchange() or possibly compiler?

> Don, > > Looks like you hit the same thing, although apparently you > saw it under > InterlockedAnd(). Mine was under InterlockedOr()... That's a little > scary. This could be lurking in other InterlockedXxxx() > functions, and > perhaps I should check our code base for all occurrences. > > Your comments about the register tracking logic and <...excess quoted lines suppressed...> It's an assumption, based on some knowledge of compiler internals (but not the DDK compiler). It could be for some other reason (although, at the moment I can't think of any: we have wrong behaviour that goes away providing you put code between the interlocked operation and the test). I can't remember the details, but I'm pretty sure I did try inserting some code between the interlocked operation and the test. When it still didn't work, I discovered the optimiser had removed the inserted code. I could be wrong though, it was a couple of years ago. > If you're sure, I'll add your comments to my MS bug report to > maybe help > them evaluate the bug. The reason I ask is that I'm building for > checked x86 here; I actually wouldn't expect much optimization to be > done by the compiler -- but I don't really know. The bug isn't about optimisation, I believe it's a mistake in the register tracking logic, although as you correctly point out, that's an assumption. My point is that you have to put something between the Interlocked operation and the test: something that means that the compiler can no longer mistakenly assume it knows the value of the condition registers. The danger of doing something local is that it works in the checked build, but your bug comes back when the optimiser elides your code. I put in a function call, which had (benign) side effects, so I could be pretty damn sure that wasn't going to happen. > > Anyway, thanks! > > Oh, by the way, my compilation is under Visual Studio 2003's > C compiler. > I wonder if 2005 has maybe fixed this problem (I didn't try that)... Nor have I. Don

Message 10 of 14

19 May 06 01:01

Doron Holan

xxxxxx@microsoft.com

Join Date: 08 Sep 2005

Posts To This List: 5313

RE: Bug with InterlockedExchange() or possibly compiler?

Any reason why you aren't using the DDK's cl.exe? -- I can spell, I just can't type. -----Original Message----- From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Suffin, Charlie Sent: Thursday, May 18, 2006 4:58 PM To: Windows System Software Devs Interest List Subject: RE: [ntdev] Bug with InterlockedExchange() or possibly compiler? Peter, I'm building this driver on my XP laptop, but it's the Windows 2003 SP1 DDK with Visual 2003 cl compiler. The code listing says this: ; Listing generated by Microsoft (R) Optimizing Compiler Version 13.10.4035 Hope that helps... -- Charlie --- Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Message 11 of 14

19 May 06 07:22

Charlie Suffin

xxxxxx@egenera.com

Join Date: 18 May 2006

Posts To This List: 9

RE: Bug with InterlockedExchange() or possibly compiler?

Doron, folks, Ooops, I'm so sorry about the confusion. Until this moment I didn't understand that the DDK came with its own compiler. I've always had the Visual tools loaded on systems where I've done driver work and I assumed that that compiler was used. Silly me! So, I misstated. The InterlockedXxxx() problem of testing the result value against zero occurs on my system with the Windows DDK 3790.1830. Our specific example was built with a Windows Server 2003 Checked x86 Build Environment command window. cl reports the following version: C:\WINDDK\3790~1.183>cl.exe Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.4035 for 80x86 Copyright (C) Microsoft Corporation 1984-2002. All rights reserved. I should note that the Studio .NET 2003 compiler on my box actually appears to be older, if I'm understanding these revs correctly (vc7's cl.exe shows 13.10.3077). But let me clarify, that's *not* the compiler I am using. I'm using the DDK compiler (13.10.4035). I didn't try any of this with earlier DDKs. If you guys think narrowing the problem down that way is useful, let me know what you think I should test. As based on what Don W. was saying earlier, I suspect this problem could be present back a ways... Oh, one other thing (good news), I just compiled this for x64, and the problem doesn't seem to exist in that environment! The compiler *does* emit a cmp instruction before the jne. Note, the DDK compiler rev for x64 is 14.00.40310.41. So, perhaps the problem was fixed in major rev 14 of cl?? Anyway, here is the x64 code, for reference, see how offset 1103 differs from the x86 version: ; 3324 : ; 3325 : ULONG prevState; ; 3326 : prevState = InterlockedOr(&pCmdBlock->State, 0x4); 010bb 48 8b 84 24 78 01 00 00 mov rax, QWORD PTR pCmdBlock$[rsp] 010c3 48 83 c0 4c add rax, 76 ; 0000004cH 010c7 48 89 84 24 40 01 00 00 mov QWORD PTR tv849[rsp], rax 010cf 48 8b 84 24 40 01 00 00 mov rax, QWORD PTR tv849[rsp] 010d7 0f 0d 08 prefetchw BYTE PTR [rax] 010da 48 8b 8c 24 40 01 00 00 mov rcx, QWORD PTR tv849[rsp] 010e2 8b 01 mov eax, DWORD PTR [rcx] $LL120@CompleteSc@2: 010e4 8b d0 mov edx, eax 010e6 83 ca 04 or edx, 4 010e9 48 8b 8c 24 40 01 00 00 mov rcx, QWORD PTR tv849[rsp] 010f1 48 8b 8c 24 40 01 00 00 mov rcx, QWORD PTR tv849[rsp] 010f9 f0 0f b1 11 lock cmpxchg DWORD PTR [rcx], edx 010fd 75 e5 jne SHORT $LL120@CompleteSc@2 010ff 89 44 24 58 mov DWORD PTR prevState$29717[rsp], eax ; 3327 : if (prevState == 0) 01103 83 7c 24 58 00 cmp DWORD PTR prevState$29717[rsp], 0 01108 75 0c jne SHORT $LN66@CompleteSc@2 ; 3328 : { ; 3329 : KdPrint(("HUH!\n")); 0110a 48 8d 0d 00 00 00 00 lea rcx, OFFSET FLAT:??_C@_0L@EAGOAJOD@?4textHUH?$CB?6?$AA@ 01111 e8 00 00 00 00 call DbgPrint $LN66@CompleteSc@2: -----Original Message----- From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan Sent: Friday, May 19, 2006 12:54 AM To: Windows System Software Devs Interest List Subject: RE: [ntdev] Bug with InterlockedExchange() or possibly compiler? Any reason why you aren't using the DDK's cl.exe? -- I can spell, I just can't type.

Message 12 of 14

19 May 06 14:42

don ward

xxxxxx@careful.co.uk

Join Date: 03 Dec 2004

Posts To This List: 107

RE: Bug with InterlockedExchange() or possibly compiler?

> > Oh, one other thing (good news), I just compiled this for x64, and the > problem doesn't seem to exist in that environment! The > compiler *does* > emit a cmp instruction before the jne. Note, the DDK compiler rev for > x64 is 14.00.40310.41. So, perhaps the problem was fixed in major rev > 14 of cl?? I doubt it. Different target means different back end (different register logic, different optimiser, different code generator etc.). Don

Message 13 of 14

19 May 06 19:20

ntdev member 26176

xxxxxx@writeme.com

Join Date:

Posts To This List: 252

Re: Bug with InterlockedExchange() or possibly compiler?

"Suffin, Charlie" <xxxxx@egenera.com> wrote in message news:78527@ntdev... >Oh, by the way, my compilation is under Visual Studio 2003's C compiler. >I wonder if 2005 has maybe fixed this problem (I didn't try that)... VS 2003 seems to have some bugs fixed only in VS2005. For example, a bug reported by Cristalink some time ago against VS2003 has resolution "fixed in vs2005" on the MSFT feedback site. Maybe SP1 for vs2003 will fix some of these issues. --PA

Message 14 of 14

20 May 06 03:15

Maxim S. Shatskih

xxxxxx@storagecraft.com

Join Date: 20 Feb 2003

Posts To This List: 6526

Re: Bug with InterlockedExchange() or possibly compiler?

BTW - from what I remember, InterlockedAnd/Or are macros around usual "and/or" and InterlockedCompareExchange in a loop. Like: LONG InterlockedOr(LONG* Variable, LONG OrVal) { LONG OldVal; LONG NewVal; for(;;) { OldVal = *Variable; NewVal = OldVal | OrVal; if( InterlockedCompareExchange(Variable, NewVal, OldVal) == OldVal ) break; } return OldVal; } See the DDK headers for more details. Maxim Shatskih, Windows DDK MVP StorageCraft Corporation xxxxx@storagecraft.com http://www.storagecraft.com

Posting Rules
You may not post new threads You may not post replies You may not post attachments	You must login to OSR Online AND be a member of the ntdev list to be able to post.

All times are GMT -5. The time now is 13:43.

Contact Us - Osr Online Homepage - Top