[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] test_x86_emulator



>>> On 14.04.14 at 19:29, <dslutz@xxxxxxxxxxx> wrote:
> It is more complex then it appears at 1st look.
> 
> -O1:
> ...
> Testing movdqu (%edx),%xmm4...          okay
> Testing vmovdqu %ymm2,(%ecx)...         skipped
> Testing vmovdqu (%edx),%ymm4...         skipped
> Testing movsd %xmm5,(%ecx)...           okay
> Testing movaps (%edx),%xmm7...          okay
> ...
> 
> -O2:
> ...
> Testing movdqu (%edx),%xmm4...          okay
> Testing vmovdqu %ymm2,(%ecx)...         failed!
> make: *** [run] Error 1

Now that's of course very interesting - looks more like a problem
with test_x86_emulator.c's use of CPUID then (because you said
you do this on an AVX-capable system, the -O1 test shouldn't skip
these).

> get_fpu (exception_callback=0x402a60 <fpu_handle_exception>, 
> exception_callback_arg=0x7fffffffd7d0,
>      type=X86EMUL_FPU_ymm, ctxt=0x7fffffffdb80) at test_x86_emulator.c:138
> 138         switch ( type )
> (gdb) n
> 137     {
> (gdb)
> 138         switch ( type )
> (gdb)
> 154         return X86EMUL_OKAY;
> (gdb)
> 138         switch ( type )
> (gdb)
> 152             return X86EMUL_UNHANDLEABLE;
> (gdb)
> 138         switch ( type )
> (gdb)
> 132     int get_fpu(
> (gdb)
> 155     }

Or a code generation problem: An input of X86EMUL_FPU_ymm should
obviously result in execution making to the respective case statement,
yet the steps above lead directly to the default one.

What gcc version are you using? And could you perhaps make both
binaries (-O1 and -O2) available for inspection?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.