[Mesa-dev] Build mesa-dev on Windows with AVX instruction set problem

[Fabrício Ceolin]

Seeing the source code in disassembly and the stacktrace, it appears to me
that the problem is in the std:: basic_string(), not related to mesa-dev.

Although, it's strange to me the source of this include is at MSVC dir
(according to VS2017) and opengl32.dll was compiled using LLVM. Maybe the
problem is LLVM compilation, not the mesa-dev compilation.

Disassembly with source:

  1922: basic_string(const basic_string& _Right)
  1923: :
_Mybase(_Alty_traits::select_on_container_copy_construction(_Right._Getal()))
00007FF85FBF874B 48 89 41 18          mov         qword ptr [rcx+18h],rax
  1925: _Construct_lv_contents(_Right);
00007FF85FBF874F 48 83 7A 18 10       cmp         qword ptr [rdx+18h],10h
00007FF85FBF8754 48 8B 6A 10          mov         rbp,qword ptr [rdx+10h]
00007FF85FBF8758 72 03                jb
 std::basic_string<char,std::char_traits<char>,std::allocator<char>
>::basic_string<char,std::char_traits<char>,std::allocator<char> >+2Dh
(07FF85FBF875Dh)
00007FF85FBF875A 48 8B 32             mov         rsi,qword ptr [rdx]
00007FF85FBF875D 48 83 FD 10          cmp         rbp,10h
00007FF85FBF8761 73 27                jae
std::basic_string<char,std::char_traits<char>,std::allocator<char>
>::basic_string<char,std::char_traits<char>,std::allocator<char> >+5Ah
(07FF85FBF878Ah)
00007FF85FBF8763 C5 F8 10 06          vmovups     xmm0,xmmword ptr [rsi]
00007FF85FBF8767 C5 F8 11 01          vmovups     xmmword ptr [rcx],xmm0
00007FF85FBF876B 48 89 69 10          mov         qword ptr [rcx+10h],rbp


Include path of source in disassembly: c:\Program Files (x86)\Microsoft
Visual Studio\2017\Community\VC\Tools\MSVC\14.11.25503\include\xstring


Stacktrace:

>
opengl32.dll!std::basic_string<char,std::char_traits<char>,std::allocator<char>
>::basic_string<char,std::char_traits<char>,std::allocator<char> >(const
std::basic_string<char,std::char_traits<char>,std::allocator<char> > &
_Right) Line 1925 C++ Symbols loaded.
  [External Code] Annotated Frame
  opengl32.dll!_initterm(void(*)() * first, void(*)() * last) Line 16 C++
Symbols loaded.
  [External Code] Annotated Frame
  python36.dll!000000005e137fd8() Unknown No symbols loaded.
  python36.dll!000000005e1376ca() Unknown No symbols loaded.
  python36.dll!000000005e1372a1() Unknown No symbols loaded.
  python36.dll!000000005e137217() Unknown No symbols loaded.

[image: MiningMath Associates]
<http://www.miningmath.com/component/content/article/4.html?src=ass&mdm=email&cpn=FAC#Fabrício+Ceolin>
*Fabrício
Ceolin*
+55 (31) 98675-1359
MiningMath Associates <http://www.miningmath.com/?src=ass&mdm=email&cpn=FAC>
www.miningmath.com <http://www.miningmath.com/?src=ass&mdm=email&cpn=FAC>



2017-10-25 20:55 GMT-02:00 Roland Scheidegger <sroland at vmware.com>:

> Am 26.10.2017 um 00:26 schrieb Ilia Mirkin:
> > On Wed, Oct 25, 2017 at 6:15 PM, Fabrício Ceolin
> > <fabricio.ceolin at miningmath.com <mailto:fabricio.ceolin at miningmath.com>>
> > wrote:
> >
> >     Hi,
> >
> >     Thanks. I recompiled everything (on Windows) using this real machine:
> >
> >     #under msys2
> >     $ cat /proc/cpuinfo
> >     processor       : 0
> >     vendor_id       : GenuineIntel
> >     cpu family      : 6
> >     model           : 23
> >     model name      : Genuine Intel(R) CPU           U2300  @ 1.20GHz
> >     stepping        : 10
> >     cpu MHz         : 1197.000
> >     cache size      : 1024 KB
> >     physical id     : 0
> >     siblings        : 2
> >     core id         : 0
> >     cpu cores       : 2
> >     apicid          : 0
> >     initial apicid  : 0
> >     fpu             : yes
> >     fpu_exception   : yes
> >     cpuid level     : 13
> >     wp              : yes
> >     flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr
> >     pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
> >     pbe pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm xsave
> >     osxsave lahf_lm dtherm
> >     clflush size    : 64
> >     cache_alignment : 64
> >     address sizes   : 36 bits physical, 48 bits virtual
> >     power management:
> >
> >     but I got the same error:
> >
> >     00007FF85FBF874F 48 83 7A 18 10       cmp         qword ptr
> >     [rdx+18h],10h
> >     00007FF85FBF8754 48 8B 6A 10          mov         rbp,qword ptr
> >     [rdx+10h]
> >     00007FF85FBF8758 72 03                jb
> >     std::basic_string<char,std::char_traits<char>,std::allocator<char>
> >     >::basic_string<char,std::char_traits<char>,std::allocator<char>
> >     >+2Dh (07FF85FBF875Dh)
> >     00007FF85FBF875A 48 8B 32             mov         rsi,qword ptr
> [rdx]
> >     00007FF85FBF875D 48 83 FD 10          cmp         rbp,10h
> >     00007FF85FBF8761 73 27                jae
> >      std::basic_string<char,std::char_traits<char>,std::allocator<char>
> >     >::basic_string<char,std::char_traits<char>,std::allocator<char>
> >     >+5Ah (07FF85FBF878Ah)
> >     *00007FF85FBF8763 C5 F8 10 06          vmovups     xmm0,xmmword ptr
> >     [rsi]  *
> >     00007FF85FBF8767 C5 F8 11 01          vmovups     xmmword ptr
> >     [rcx],xmm0
> >     00007FF85FBF876B 48 89 69 10          mov         qword ptr
> >     [rcx+10h],rbp
> >
> >     Are there any parameters that I can use for avoid to use AVX (or
> >     better) instructions?
> >
> >
> > LP_NATIVE_VECTOR_WIDTH=128 should force you to a non-avx path. There's
> > also a LP_FORCE_SSE2=1 which will also avoid sse3/4 usage. However all
> > this stuff should be getting detected, so it's odd that it's messing up.
> > Perhaps run with GALLIUM_DUMP_CPU=1 to see what's being detected?
> >
>
> Also, a backtrace when it crashes would be nice. I am not convinced this
> is actually happening inside a code-generated shader...
>
> Roland
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20171025/b12635fc/attachment-0001.html>