From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: Cygwin bash's built-in test command crashes on Windows 2008 Server 64bit under KVM Date: Fri, 13 Feb 2009 23:02:14 +0200 Message-ID: <4995DFD6.7050605@redhat.com> References: <40ddf2480901050654y268213d1jbf34f9d81d6faeb0@mail.gmail.com> <40ddf2480901050822q52a9c2b6x5d5d87d17dec4992@mail.gmail.com> <49788A80.2070403@redhat.com> <87bptgnykd.fsf@fftw.org> <4995D180.9000706@redhat.com> <878woaozu2.fsf@matteo.cilk.lan> <4995D7FD.9020609@redhat.com> <87eiy26ph9.fsf@cilk.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------060904060307030801090102" Cc: kvm@vger.kernel.org To: Matteo Frigo Return-path: Received: from mx2.redhat.com ([66.187.237.31]:57446 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752710AbZBMVBu (ORCPT ); Fri, 13 Feb 2009 16:01:50 -0500 In-Reply-To: <87eiy26ph9.fsf@cilk.com> Sender: kvm-owner@vger.kernel.org List-ID: This is a multi-part message in MIME format. --------------060904060307030801090102 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Matteo Frigo wrote: > Avi Kivity 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. --------------060904060307030801090102 Content-Type: text/x-csrc; name="gs.c" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="gs.c" #include 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; } --------------060904060307030801090102--