Re: Cygwin bash's built-in test command crashes on Windows 2008 Server 64bit under KVM

[Avi Kivity <avi@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 3098 bytes --]

Matteo Frigo wrote:
> Avi Kivity <avi@redhat.com> 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.


[-- Attachment #2: gs.c --]
[-- Type: text/x-csrc, Size: 343 bytes --]

#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;
}