I've playing around SEH and found an interesting bug. The program is very easy

gotcha db "Gotcha!!!",0
align 4
failed db "Failed!!!",0
assume fs:nothing
push offset handler
push fs:[0]
mov fs:[0], esp
int 3
invoke MessageBox,0,addr failed,addr failed,0
jmp @F
invoke MessageBox,0,addr gotcha,addr gotcha,0
mov eax, [esp]
mov fs:[0], eax
add esp, 8
invoke ExitProcess,0

handler proc
mov edx, [esp+12] ; get ContextRecord
mov eax, offset @@gotcha
mov [edx].CONTEXT.regEip, eax
xor eax, eax
handler endp
end start

The problem is this code pops "Gotcha" on any processors except those I mention in the subject. Is there any explanations? I know K6 have some bugs but I don't remember that one...
Posted on 2004-04-27 09:16:19 by masquer
I think you have hit a case of a well known difference of the K6 from the IA32 template,
which was found and signalled long ago (by Elicz IIRC). The one-byte "int 3" opcode generating exception (trap) 3 on Intel but as interrupt 3 on K6. How that minor glimpse in the (otherwise remarkable) emulation of IA32 by K6 causes your observed difference, it would require to look carefully at all the DPLs/CPLs involved - if I were to investigate that difference of course I would not do it under Windows (any version) because it makes such an awfull mess withf the Intel protection model and features (Unix is no better in this respect IMO:=)

Anywayzzz you could quickly try comparing the results you get with your small demo, only replacing the one-byte "int 3" (hex CC) by 2-byte interrupt 3 ( CD 03) . I bet the result would be different from what you got here, and would then be the same for Intel vs. AMD. I do not try to guess however which precise behavior you'll observe :=)

HTH , please post again any findingz

Posted on 2004-04-28 09:20:42 by Czerno
Elicz was found a little different bug in K6.
In my case I guess it was just a crippled processor, because the number of K6 I did check behave exactly as they should
Posted on 2004-04-29 02:17:59 by masquer
You're right, the bug Elicz found is about the one-byte int1 opcode (hex F1), not int3.
I seem to be needing some rest ;)

> In my case I guess it was just a crippled processor,

Glad to hear the K6 does int3 properly after all !

what kind of K6-x is it (rev id?) By crippled, do you mean it's eventually
gone defective, or did it (mis)behave by (wrong, early maybe) design from AMD ? Does the BIOS POST signal anythin' wrong with that proc ? Can you assert EAX being zero or not after self-test (reset) ? Does this chip exhibit other verified problems ?

Reason I ask is I find it scary to think that processors could grow unnoticed defects of a kind that still are not caught by the BIST nor impede the launching of a large OS machinery !!!

Posted on 2004-04-30 03:11:16 by Czerno