Matteo Frigo wrote:
Avi Kivity <avi@xxxxxxxxxx> writes:
- run a cygwin program in an infinite loop (while :; do :; done is
sufficient)
- 'info registers', look at gdt
- 'x/28x 0x$GDT'
I'm interested in offset 0x28, but please provide the whole thing for
sanity checking.
Here it is. This is with npt=1, but npt=0 shows exactly the
same GDT.
(qemu) info registers
EAX=0022dad8 EBX=00230000 ECX=61108b28 EDX=0043fea7
ESI=00000014 EDI=00000000 EBP=0022c518 ESP=0022c4f4
EIP=610935e2 EFL=00000202 [-------] CPL=3 II=0 A20=1 SMM=0 HLT=0
ES =002b 0000000000000000 ffffffff 00c0f300
CS =0023 0000000000000000 ffffffff 00c0fb00
SS =002b 0000000000000000 ffffffff 00c0f300
DS =002b 0000000000000000 ffffffff 00c0f300
FS =0053 000000007efdd000 00000fff 0040f300
GS =002b 000000007efdb000 ffffffff 00c0f300
LDT=0000 0000000000000000 0000ffff 00000000
TR =0040 fffff800004e8070 00000068 00008b00
GDT= fffff800004e7000 0000006f
IDT= fffff800004e7070 00000fff
CR0=80050031 CR2=000007ff7dd13000 CR3=000000002d62c000 CR4=000006f8
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
DR6=00000000ffff0ff0 DR7=0000000000000400
FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00000000
FPR0=0000000000000000 0000 FPR1=0000000000000000 0000
FPR2=0000000000000000 0000 FPR3=0000000000000000 0000
FPR4=0000000000000000 0000 FPR5=0000000000000000 0000
FPR6=0000000000000000 0000 FPR7=0000000000000000 0000
XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000
XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000
XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000
XMM06=000000007ffe00300000000000160014 XMM07=00000000000000000000000000000000
(qemu) x/28x 0xfffff800004e7000
fffff800004e7000: 0x00000000 0x00000000 0x00000000 0x00000000
fffff800004e7010: 0x00000000 0x00209b00 0x0000ffff 0x00cf9300
fffff800004e7020: 0x0000ffff 0x00cffb00 0x0000ffff 0x00cff300
fffff800004e7030: 0x00000000 0x0020fb00 0x00000000 0x00000000
fffff800004e7040: 0x80700068 0x00008b4e 0xfffff800 0x00000000
fffff800004e7050: 0xd0000fff 0x7e40f3fd 0x00000000 0x00000000
fffff800004e7060: 0x0000ffff 0x00cf9b00 0x00000000 0x00000000
According to the GDT, gs:base will be zero after executing the 'mov gs'
instruction (but gs:base is not zero prior, as seen in 'info
registers'). This is the same info I get on Intel, so it seems the GDT
is maintained correctly.
More questions:
- is the bad 'mov gs' instruction reached on AMD? or is it avoided
somehow? What about bare metal?
- does the attached program fail when compiled and run in cygwin on an
AMD host?
- does setjmp()/longjmp() come from the Windows run-time library, or
from cygwin?
I note that ds, es, ss, and gs all contain the same selector, so I don't
see how longjmp() can expect that gs.base will not be clobbered after
executing 'mov gs'.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
#include <stdio.h>
int main()
{
unsigned short gs;
unsigned x;
asm ("mov %%gs, %0\n" : "=g"(gs));
asm ("movl %%gs:0x30, %0\n" : "=r"(x));
printf("gs: %x\n", gs);
printf("gs:0x30: %x\n", x);
asm ("mov %0, %%gs\n" : : "g"(gs));
printf("test\n");
asm ("movl %%gs:0x30, %0\n" : "=r"(x));
return 0;
}
