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: 1415 bytes --]

Matteo Frigo wrote:
> Avi Kivity <avi@redhat.com> writes:
>
>   
>> More questions:
>> - is the bad 'mov gs' instruction reached on AMD?  or is it avoided
>> somehow?  What about bare metal?
>>     
>
> The instruction is indeed reached on amd, and gs is 0x2b after
> the instruction.  I don't know about bare metal.
>
>   
>> - does the attached program fail when compiled and run in cygwin on an
>> AMD host?
>>     
>
> The program runs as follows:
>
> w2k3-64:/cygdrive/v$ gcc -O gs.c
> w2k3-64:/cygdrive/v$ ./a.exe 
> gs: 2b
> gs:0x30: 7efdb000
> test
>
>   
>> - does setjmp()/longjmp() come from the Windows run-time library, or 
>> from cygwin?
>>     
>
> The setjmp()/longjmp() is in the cygwin library /bin/cygwin1.dll .
> bash calls longjmp() at the end of the expr built-in, which causes the
> problem reported by the original poster.
>
> I should also mention that, as an experiment, I have replaced the mov
> gs,ax instruction with a couple of no-ops in cygwin1.dll, and cygwin
> runs fine on Intel with this patch.
>
>   

That was going to be my next question :)

Right now I don't understand how cygwin's longjmp() is supposed to work 
at all, given that it clobbers gs.

Can you run the slightly modified gs.c (attached) and rerun on AMD?  The 
is to see if the runtime somehow restores 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: 371 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 volatile ("mov %0, %%gs\n" : : "g"(gs));

    asm volatile ("movl %%gs:0x30, %0\n" : "=r"(x));

    printf("gs:0x30: %x\n", x);

    return 0;
}