Yep, one of those features, that you canThere is a "semi-official" bug in Intel CPUs,Not a bug, but a feature.
which is described here:
http://www.intel.com/design/intarch/specupdt/27287402.PDF
chapter "Specification Clarifications"
section 4: "Use Of ESP In 16-Bit Code With 32-Bit Interrupt Handlers".
I expected that. My last hopes were on Cyrix, which,What I want to find out, is what CPUs areAFAIK all.
affected. I wrote a small test-case. It is
attached. I tried it on Intel Pentium and
on AMD Athlon - bug is present on both. But
I'd like to know if it is also present on a
Transmeta Crusoe, Cyrix and other CPUs.
There are products which depend on this behavior.Out of curiosity, what are those products? I
Hmm, that sounds feasible.I'd also like to know any thoughts on whetherIMHO you have to switch to 16bit stack, load upper bits of ESP with target value, and then execute IRET, while 16bit SS:SP points to same place where flat ESP pointed.
it is possible to work around the bug, probably
in a kernel?
And I do not think that linux NMI handler survives 16bit stack, so natural solution seems to be to create complete 16bit CPL1 environment, return to it, load ESP as you want, and then do IRET to return to CPL2 or CPL3. Fortunately V8086 mode is not affected, so there should be no problem with using CPL1 for this middle step. But of course it is not something you want to do on each return from interrupt handler... Well, or maybe you want...Umm, no. But well, the spec claims that this
How could that happen? Was it so difficult to justAnyway, I'd be glad to get any info on that bug.It is part of architecture now...
Why it was not fixed for so many years, looks
also like an interesting question, as for me.