Segfault with radeonsi in LLVMAddTargetDependentFunctionAttr

[ChristophHaag]

wine-1.7.55 with latest nine patches from git.
Latest mesa git.
llvm-svn 253143.

Everything crashes with nine, but works with wined3d.
Backtrace with debug mesa:
https://gist.githubusercontent.com/ChristophHaag/b277cee468a06dec275e/raw/1c834b35e1e039ba0939b830ec4f39d76834b7c4/gistfile1.txt

[axeldavy]

This looks like some incompatibility llvm svn vs mesa git, but I don't explain why you'd hit it with nine only.

[ChristophHaag]

Archlinux with llvm svn 254142 and latest mesa git + ixit git and latest wine git + ixit git and it still happens.

Can anyone reproduce it? Can anyone not reproduce it with similar versions?

[Korvox]

I have this bug as well, it happens with both Arch's stock Mesa (currently 11.0.7) and stock LLVM (currently 3.7) and mesa-git + llvm-svn. Heres the crash report it spits out, which shows it happening in the same call chain as the OP. It happens in anything using d3dadapter.so for me, so this seems reproducible with AMD hardware on Arch. I have a 290 for reference in case this is some device-specific issue.

[ChristophHaag]

HD 7970M for me. Should we report this upstream at mesa? Then someone who also works on the llvm side could take a look at it. But first, a backtrace with full debug info for llvm might be good to have.

[pontostroy]

I am on opensuse 42.1 (gcc 4.8) and every 3-5 days i build llvm\mesa snapshot and nine always works fine.
Maybe it's gcc 5 or arch specific problem

[nicman23]

log from #178

fixme:module:load_dll Loader redirect from L"d3d9.dll" to L"d3d9-nine.dll"
fixme:win:EnumDisplayDevicesW ((null),0,0x32f724,0x00000000), stub!
fixme:win:EnumDisplayDevicesW (L"\\\\.\\DISPLAY1",0,0x32f724,0x00000000), stub!
fixme:win:EnumDisplayDevicesW (L"\\\\.\\DISPLAY1",1,0x32f724,0x00000000), stub!
fixme:win:EnumDisplayDevicesW ((null),1,0x32f724,0x00000000), stub!
fixme:d3dadapter:d3dadapter9_new 
Native Direct3D 9 is active.
For more information visit https://wiki.ixit.cz/d3d9
fixme:win:EnumDisplayDevicesW (L"\\\\.\\DISPLAY1",0,0x32f6b4,0x00000000), stub!
fixme:d3dadapter:DRI3PresentGroup_GetMultiheadCount (0x13d5b0), stub!
fixme:d3dadapter:DRI3PresentGroup_GetMultiheadCount (0x13d5b0), stub!
wine: Unhandled page fault on read access to 0xffffffff at address 0x7942b2fb (thread 003a), starting debugger...
Unhandled exception: page fault on read access to 0xffffffff in 32-bit code (0x7942b2fb).
Register dump:
 CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b
 EIP:7942b2fb ESP:0032afc8 EBP:0032b09c EFLAGS:00010212(  R- --  I   -A- - )
 EAX:0032b052 EBX:7df2b000 ECX:7ffffffe EDX:0032afe4
 ESI:0032b052 EDI:7ce8bb84
Stack dump:
0x0032afc8:  7ce86cd0 f750cc60 00000000 793f989c
0x0032afd8:  00000000 7b7dd000 f744f769 7df2b000
0x0032afe8:  0032b052 7ce8bb84 0032b09c f744f740
0x0032aff8:  0032b052 00000001 00000002 7ddfd778
0x0032b008:  0032b038 7ce6d2f8 0032b02c 7ce8bb84
0x0032b018:  00000000 00000001 00000016 7df2b000
000c: sel=0067 base=00000000 limit=00000000 16-bit --x
Backtrace:
=>0 0x7942b2fb LLVMAddTargetDependentFunctionAttr+0x1b() in libllvm.so.3.7 (0x0032b09c)
  1 0x7ddc1d7f in d3dadapter9.so.1 (+0x3bed7e) (0x0032b09c)
  2 0x7dd35048 in d3dadapter9.so.1 (+0x332047) (0x0032b09c)
  3 0x7dd3c860 in d3dadapter9.so.1 (+0x33985f) (0x7ce8afd0)
  4 0x7dd46b14 in d3dadapter9.so.1 (+0x343b13) (0x7cdf3540)
  5 0x7dd47366 in d3dadapter9.so.1 (+0x344365) (0x7cdf3540)
  6 0x7dd43fbb in d3dadapter9.so.1 (+0x340fba) (0x7cdf3c04)
  7 0x7da6fb6d in d3dadapter9.so.1 (+0x6cb6c) (0x00000000)
  8 0x7ddb4359 in d3dadapter9.so.1 (+0x3b1358) (0x7ce44430)
  9 0x7da6e9d0 in d3dadapter9.so.1 (+0x6b9cf) (0x0032fa84)
  10 0x7dd2dd37 in d3dadapter9.so.1 (+0x32ad36) (0x7cdf3540)
  11 0x7dd2e57c in d3dadapter9.so.1 (+0x32b57b) (0x7df2b000)
  12 0x7db838b8 in d3dadapter9.so.1 (+0x1808b7) (0x7df2b000)
  13 0x7db03023 in d3dadapter9.so.1 (+0x100022) (0x00000000)
  14 0x0040118f in dx9_initialization (+0x118e) (0x7e78b850)
  15 0x4c8d5dec (0x8b55ff8b)
0x7942b2fb LLVMAddTargetDependentFunctionAttr+0x1b in libllvm.so.3.7:   
Modules:
Module  Address         Debug info  Name (84 modules)
PE    400000-  40d000   Export          dx9_initialization
ELF 79026000-7b800000   Dwarf           libllvm.so.3.7
ELF 7b800000-7ba69000   Deferred        kernel32<elf>
  \-PE  7b810000-7ba69000   \               kernel32
ELF 7bc00000-7bcf6000   Deferred        ntdll<elf>
  \-PE  7bc10000-7bcf6000   \               ntdll
ELF 7bf00000-7bf04000   Deferred        <wine-loader>
ELF 7d852000-7d86b000   Deferred        libresolv.so.2
ELF 7d86b000-7d88c000   Deferred        libudev.so.1
ELF 7da03000-7df79000   Dwarf           d3dadapter9.so.1
ELF 7e105000-7e10b000   Deferred        libtxc_dxtn.so
ELF 7e10b000-7e111000   Deferred        libattr.so.1
ELF 7e111000-7e116000   Deferred        libcap.so.2
ELF 7e116000-7e130000   Deferred        libgcc_s.so.1
ELF 7e130000-7e14a000   Deferred        libelf.so.1
ELF 7e14a000-7e154000   Deferred        libdrm_amdgpu.so.1
ELF 7e1b4000-7e1bf000   Deferred        libxcursor.so.1
ELF 7e1bf000-7e1d2000   Deferred        libxi.so.6
ELF 7e1d2000-7e1d6000   Deferred        libxcomposite.so.1
ELF 7e1d6000-7e1e3000   Deferred        libxrandr.so.2
ELF 7e1e3000-7e1ef000   Deferred        libxrender.so.1
ELF 7e1ef000-7e1f3000   Deferred        libxinerama.so.1
ELF 7e1f6000-7e204000   Deferred        libdrm_radeon.so.1
ELF 7e204000-7e20d000   Deferred        libdrm_nouveau.so.2
ELF 7e22f000-7e2c4000   Deferred        winex11<elf>
  \-PE  7e240000-7e2c4000   \               winex11
ELF 7e2c4000-7e2e8000   Deferred        imm32<elf>
  \-PE  7e2d0000-7e2e8000   \               imm32
ELF 7e31d000-7e359000   Deferred        libfontconfig.so.1
ELF 7e359000-7e3ce000   Deferred        libpcre.so.1
ELF 7e3ce000-7e4f4000   Deferred        libglib-2.0.so.0
ELF 7e4f4000-7e55c000   Deferred        libharfbuzz.so.0
ELF 7e55c000-7e599000   Deferred        libpng16.so.16
ELF 7e599000-7e5aa000   Deferred        libbz2.so.1.0
ELF 7e5aa000-7e66d000   Deferred        libfreetype.so.6
ELF 7e66d000-7e6db000   Deferred        libncursesw.so.6
ELF 7e717000-7e872000   Deferred        user32<elf>
  \-PE  7e730000-7e872000   \               user32
ELF 7e872000-7e997000   Deferred        gdi32<elf>
  \-PE  7e880000-7e997000   \               gdi32
ELF 7e997000-7ea0f000   Deferred        advapi32<elf>
  \-PE  7e9a0000-7ea0f000   \               advapi32
ELF 7ea0f000-7ea18000   Deferred        librt.so.1
ELF 7ea18000-7ea21000   Deferred        libffi.so.6
ELF 7ea21000-7ea32000   Deferred        libwayland-server.so.0
ELF 7ea32000-7ea3f000   Deferred        libwayland-client.so.0
ELF 7ea3f000-7ea4e000   Deferred        libgbm.so.1
ELF 7ea4e000-7ea60000   Deferred        libdrm.so.2
ELF 7ea60000-7ea67000   Deferred        libxxf86vm.so.1
ELF 7ea67000-7ea6a000   Deferred        libxshmfence.so.1
ELF 7ea6a000-7ea72000   Deferred        libxcb-sync.so.1
ELF 7ea72000-7ea77000   Deferred        libxcb-shape.so.0
ELF 7ea77000-7ea82000   Deferred        libxcb-render.so.0
ELF 7ea82000-7ea92000   Deferred        libxcb-randr.so.0
ELF 7ea92000-7ea98000   Deferred        libxcb-dri2.so.0
ELF 7ea98000-7eab3000   Deferred        libxcb-glx.so.0
ELF 7eab3000-7eacf000   Deferred        libglapi.so.0
ELF 7eacf000-7eaf8000   Deferred        libexpat.so.1
ELF 7eaf8000-7eb25000   Deferred        libegl.so.1
ELF 7eb25000-7ebcf000   Deferred        libgl.so.1
ELF 7ebcf000-7ebe4000   Deferred        libxext.so.6
ELF 7ebe4000-7ed33000   Deferred        libx11.so.6
ELF 7ed33000-7ed5a000   Deferred        libxcb.so.1
ELF 7ed65000-7ed7c000   Deferred        libz.so.1
ELF 7ed7c000-7ed96000   Deferred        version<elf>
  \-PE  7ed80000-7ed96000   \               version
ELF 7ef64000-7ef77000   Deferred        libnss_files.so.2
ELF 7ef77000-7efc4000   Deferred        libm.so.6
ELF 7efc4000-7efca000   Deferred        libxfixes.so.3
ELF 7efca000-7efce000   Deferred        libxdamage.so.1
ELF 7efce000-7efd5000   Deferred        libxdmcp.so.6
ELF 7efd5000-7efde000   Deferred        libxcb-xfixes.so.0
ELF 7efde000-7f000000   Deferred        d3d9-nine<elf>
  \-PE  7efe0000-7efe4000   \               d3d9
ELF f7310000-f7314000   Deferred        libxau.so.6
ELF f7316000-f731b000   Deferred        libdl.so.2
ELF f731c000-f7320000   Deferred        libxcb-present.so.0
ELF f7350000-f7353000   Deferred        libx11-xcb.so.1
ELF f7353000-f7357000   Deferred        libxcb-dri3.so.0
ELF f7357000-f7511000   Deferred        libc.so.6
ELF f7511000-f752f000   Deferred        libpthread.so.0
ELF f752f000-f76e7000   Dwarf           libwine.so.1
ELF f76e8000-f770c000   Deferred        ld-linux.so.2
ELF f770e000-f770f000   Deferred        [vdso].so
Threads:
process  tid      prio (all id:s are in hex)
00000008 winedbg.exe
    00000009    0
0000000e services.exe
    0000001e    0
    0000001d    0
    00000014    0
    00000010    0
    0000000f    0
00000012 winedevice.exe
    0000001c    0
    00000019    0
    00000018    0
    00000013    0
0000001a plugplay.exe
    00000020    0
    0000001f    0
    0000001b    0
00000023 dx9_initialization.exe
    00000024    0
00000039 (D) Z:\home\nikos\dx9_initialization\dx9_initialization.exe
    0000003a    0 <==
0000003b explorer.exe
    0000003f    0
    0000003e    0
    0000003d    0
    0000003c    0
System information:
    Wine build: wine-1.7.55
    Platform: i386 (WOW64)
    Host system: Linux
    Host version: 4.3.2-1-ck

[ChristophHaag]

Someone reported it to mesa: https://bugs.freedesktop.org/show_bug.cgi?id=93425

[ChristophHaag]

For people not reading the other thread, this crash is caused by a movaps instruction that tries to access unaligned memory:
=> 0x78f6f76e <+62>: movaps %xmm0,0x40(%esp)

I suppose this is related to how windows / wine thinks applications should be 4 byte aligned, while the linux ABI thinks stuff should be 16 byte aligned: https://bugs.archlinux.org/task/27560

So I built llvm with gcc's -mstackrealign option like this:

-DCMAKE_BUILD_TYPE=Release \
-DCMAKE_C_FLAGS:STRING="-m32 -mstackrealign" \
-DCMAKE_CXX_FLAGS:STRING="-m32 -mstackrealign" \

and it works.

[ChristophHaag]

For users of the archlinux [mesa-git] repository, there's an update for llvm now that is built with -mstackrealign. At least for me this works now.

I've also created https://bugs.archlinux.org/task/47450, let's see what they say.

[Korvox]

I've just tested several permutations of LLVM compiles as well to see what fixes this bug - for me, only the BUILD_TYPE=debug or relwithdebinfo work, and mstackrealign has no effect. I currently have my own version of lib32-llvm-libs 3.7.0-4 built as debinfo that works with d3dadapter, and has little performance impact.

[nicman23]

Everything works now with packages (llvm) from mesa-git repo. While not the best solution, the speed is worth it. Went from 9 fps to 30 in some cpu / gpu intensive scenes in fallout(nv)!

Just to be clear, the packages that more than one people are saying that work, are compiled only with mstackrealign and without changing the release type.

[axeldavy]

It looks like stackrealign is required for llvm when using nine.

[ChristophHaag]

Can this be worked around in how wine makes these calls? In the archlinux bug report the maintainer of the llvm package was not thrilled about compiling the system wide llvm installation with stackrealign.

Perhaps with

force_align_arg_pointer
On the Intel x86, the force_align_arg_pointer attribute may be applied to individual function definitions, generating an alternate prologue and epilogue that realigns the runtime stack if necessary. This supports mixing legacy codes that run with a 4-byte aligned stack with modern codes that keep a 16-byte stack for SSE compatibility. 

?

[axeldavy]

Yeah, probably we could use this attributes on nine entry functions.

[axeldavy]

Note this seems mostly required for the 32 bits build (of llvm or nine, on the two needs to have the attribute) and not for 64 bits.

[axeldavy]

The patch that fixes it for me is on master (doesn't require -mstackrealign for nine or llvm).
However It won't be sent upstream until it gets more testings, it'd be better in the meantime that package maintainers use -mstackrealign on gallium nine or llvm 32 bits builds.

[axeldavy]

Sent upstream, etc.