Multithreading – x86 reserves EFLAGS bit 1 = = 0: how can this happen?

I am using Win32 API to stop / start / check / change thread state Generally, he works very well Sometimes it fails, and I'm trying to find out why

I have a thread that forces context switching on other threads in the following ways:

thread stop
fetch processor state into windows context block
read thread registers from windows context block to my own context block
write thread registers from another context block into windows context block
restart thread

This is very useful... But... Rarely, context switching seems to fail Symptom: my multithreaded system is flying high when executing strange places of strange register contents

Context control is accomplished by:

if ((suspend_count=SuspendThread(WindowsThreadHandle))<0)
   { printf("TimeSlicer Suspend Thread failure");
      ...
   }
...
Context.ContextFlags = (CONTEXT_INTEGER | CONTEXT_CONTROL | CONTEXT_FLOATING_POINT);
if (!GetThreadContext(WindowsThreadHandle,&Context))
   {   printf("Context fetch failure");
       ...
   }

call ContextSwap(&Context); // does the context swap

if (ResumeThread(WindowsThreadHandle)<0)
   {  printf("Thread resume failure");
        ...
   }

No print statements were executed I conclude that windows believes that context operations are reliable

Oh, yes, I do know when a stopped thread is not calculated [for example, in system functions] and will not try to stop / context switch it I know this because every thread that performs anything other than computing has a thread specific "do not touch me" flag, and it is doing non computing (device driver programmers will consider this as the equivalent of the interrupt disable instruction)

Therefore, I want to know the reliability of the content of the context block I added various sanity tests to various register values extracted from the context block; You can actually make sure that ESP is normal (within the stack area defined in TIB), PC is in my desired program or in system call, etc There are no surprises here

I decided to check whether the condition code bits (EFLAGS) were read correctly; If this is wrong, it will cause the switching task to take the "wrong branch" recovery when its state is Therefore, I added the following code to verify the contents of the claimed EFLAGS register according to the Intel reference manual（ http://en.wikipedia.org/wiki/FLAGS_register ）Only EFLAGS

mov        eax,Context.EFlags[ebx]  ; ebx points to Windows Context block
   mov        ecx,eax                ; check that we seem to have flag bits
   and        ecx,0FFFEF32Ah         ; where we expect constant flag bits to be
   cmp        ecx,000000202h         ; expected state of constant flag bits
   je         @f
   breakpoint                         ; trap if unexpected flag bit status
@@:

On my win 7 amd phenom II X6 1090t (hex core), it occasionally falls into a breakpoint, ECX = 0200h Failed on my win 7 Intel i7 system I will ignore this, except that it implies that EFLAGS is not stored correctly, I doubt

According to my reading of Intel (and AMD) reference manual, the first bit is reserved and the value is always "1" I didn't see it here

Obviously, Ms populates context blocks by performing complex operations on thread stops I want them to store the status accurately This bit is not stored correctly If they don't store this bit correctly, what else do they store?

Why is the value of this bit sometimes / should be zero for any explanation?

Edit: my code dump registers and stack capture breakpoints The stack area contains context blocks as local variables The value in the stack in the appropriate offset of EFLAGS in eax and context block contains the value 0244h So the value in the context block is really wrong

Edit2: I changed the mask and comparison value to

and        ecx,0FFFEF328h         ; was FFEF32Ah where we expect flag bits to be
    cmp        ecx,000000200h

It seems to work reliably without any complaints Obviously, win7 does not correctly execute the first bit of EFLAGS, which does not seem important

Still interested in interpretation, but obviously this is not the source of my occasional context switching crash

Solution

Microsoft has a long history and wanders around where it hasn't really been used Raymond Chen gives many examples, such as using the low order of non byte aligned pointers

In this case, windows may need to store some of its thread contexts in the existing context structure and decide to use other unused bits in EFLAGS You can't do anything anyway. Windows gets this when you call setthreadcontext