[Bug 38719] New: 64-bit ARM Windows applications from Windows SDK for Windows 10 crash when accessing TEB/PEB members (AArch64 platform specific register X18 used for TEB?)
https://bugs.winehq.org/show_bug.cgi?id=38719 Bug ID: 38719 Summary: 64-bit ARM Windows applications from Windows SDK for Windows 10 crash when accessing TEB/PEB members (AArch64 platform specific register X18 used for TEB?) Product: Wine Version: 1.7.44 Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)winehq.org Reporter: focht(a)gmx.net Distribution: --- Hello folks, continuation of bug 38714 'mt.exe' runs further now but still crashes. --- snip --- ... 0027:Starting process L"Z:\\root\\wine\\64\\arm64\\mt.exe" (entryproc=0x14010ca70) 0027:fixme:heap:RtlSetHeapInformation (nil) 1 (nil) 0 stub 0027:trace:seh:raise_exception info[0]=0000000000000000 0027:trace:seh:raise_exception info[1]=0000001200000268 0027:trace:seh:call_stack_handlers calling handler at 0x7fb0d6dbbc code=c0000005 flags=0 wine: Unhandled page fault on read access to 0x1200000268 at address 0x140056d50 (thread 0027), starting debugger... 0027:trace:seh:start_debugger Starting debugger "winedbg --auto 38 64" fixme:ole:RemUnknown_QueryInterface No interface for iid {00000019-0000-0000-c000-000000000046} ... Unhandled exception: page fault on read access to 0x1200000268 in 64-bit code (0x0000000140056d50). Register dump: ARM64 EL0t Mode Pc:0000000140056d50 Sp:0000007fafe9f5a0 Lr:00000001400e94d8 Pstate:0000000020000000(--C-) x0: 000000000000003e x1: 0000000000000000 x2: 000000000000003e x3: 0000007fafe9f5f8 x4: 0000000000000001 x5: 0000007fb02900e8 x6: 0000007fb029af54 x7: 0000000000000002 x8: 0000000140140220 x9: 0000001200000238 x10:0000000000000000 x11:0000000000000000 x12:0101010101010101 x13:0000000000000028 x14:ffffffffffffffff x15:0000007fafd49a08 ip0:0000007fb0d92268 ip1:0000007f53e999c0 x18:0000007fb0f619d0 x19:0000007fafe9f628 x20:000000000000003e x21:0000007fb0290750 x22:0000007fafe9fbb8 x23:0000007fafe9f698 x24:0000007fb00cd000 x25:0000007fb02908c0 x26:0000007fdd267d80 x27:0000007fdd267cf8 x28:0000007fb00e5000 Fp:0000007fafe9f5d0 Stack dump: 0x0000007fafe9f5a0: 0000007fafe9f5c0 0000007fb0d37378 0x0000007fafe9f5b0: 0000007fafe9f5c0 0000007fb0d37510 0x0000007fafe9f5c0: 0000007fc00000e5 0000007f53e999c0 0x0000007fafe9f5d0: 0000007fafe9f650 00000001400730b0 0x0000007fafe9f5e0: 0000000000000000 000000000000001c 0x0000007fafe9f5f0: 0000007f00000000 000000000000003e 0x0000007fafe9f600: 0000007fb02908c0 0000007fdd267d80 0x0000007fafe9f610: 0000007fdd267cf8 4010040140100401 0x0000007fafe9f620: 0000000000000006 0000000000000000 0x0000007fafe9f630: 0000000000000000 0000000000000000 0x0000007fafe9f640: 0000007fafe9f670 0000007f53e99a40 0x0000007fafe9f650: 0000007fafe9f6c0 0000000140073688 Backtrace: =>0 0x0000000140056d50 in mt (+0x56d50) (0x0000007fafe9f5d0) 1 0x00000001400e94d8 in mt (+0xe94d7) (0x0000007fafe9f5d0) 0x0000000140056d50: be_arm64_disasm_one_insn: not done Modules: Module Address Debug info Name (52 modules) ELF 400000- 413000 Deferred <wine-loader> PE 140000000- 140170000 Export mt ... Threads: process tid prio (all id:s are in hex) ... 00000026 (D) Z:\root\wine\64\arm64\mt.exe 00000027 0 <== --- snip --- Since debugging is not possible as of now, an "offline" analysis at the crash location: --- snip --- ... 0000000140056D38 ADD X8, X18, #0 ; X18 = NtCurrentTeb()? 0000000140056D3C LDR X9, [X8,#0x60] ; Teb->Peb 0000000140056D40 ADRP X8, #0x140140000 ; imports segment (.idata) 0000000140056D44 ADD X2, X0, #0 ; arg3 = size 0000000140056D48 ADD X8, X8, #0x220 ; HeapAlloc 0000000140056D4C MOV W1, #0 ; arg2 = flags = 0 0000000140056D50 LDR X0, [X9,#0x30] ; arg1 = Peb->ProcessHeap 0000000140056D54 LDAR X9, [X8] 0000000140056D58 BR X9 ; HeapAlloc() --- snip --- Essentially being: HeapAlloc( GetProcessHeap(), 0, size) Further decoded: HeapAlloc( ((NtCurrentTeb()->ProcessEnvironmentBlock)->ProcessHeap), 0, size) I haven't found information on register X18 being used for TEB hence this is another guess. There is no initialization of X18 in caller chain and even in the whole app code. Running the whole .text segment through disas only reads through "ADD" and "LDR" instructions can be found. Other information sources: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20150119/254111.... ("[llvm] r226664 - AArch64: add backend option to reserve x18 (platform register)") https://android.googlesource.com/platform/art/+/63206f3%5E!/ ("AArch64: Fix the usage of Thread Register for arm64") --- quote --- This patch cleans-up the usage of x18 as TR for Arm64. As described in the Arm64 Procedure Call Standard, the recommended usage for x18 is to carry inter-procedural state (i.e. ART thread information). ... --- quote --- https://stackoverflow.com/questions/28109826/arm64-using-gas-on-ios --- quote --- X0-X7 - arguments and return value (volatile) X8 = indirect result (struct) location (or temp reg) X9-X15 = temporary (volatile) X16-X17 - intro-call-use registers (PLT, Linker) or temp X18 - platform specific use (TLS) X19-X28 - callee saved registers (non-volatile) X29 - frame pointer X30 - link register (LR) SP - stack pointer and zero (XZR) V0-V7, V16-V31 - volatile NEON and FP registers V8-V15 - callee saved registers (non-volatile, used for temp vars by compilers) --- quote --- $ sha1sum sdksetup.exe 0720e4e922ff7aa8cc78b23a00906a96c2b237a4 sdksetup.exe $ du -sh sdksetup.exe 1.2M sdksetup.exe # ./wine64 --version wine-1.7.43-178-g22983f2 Regards -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=38719 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download URL| |http://go.microsoft.com/fwl | |ink/p/?LinkId=536682 CC| |nerv(a)dawncrow.de Hardware|x86 |aarch64 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=38719 --- Comment #1 from André H. <nerv(a)dawncrow.de> --- Awesome, seems like we don't need to mess with the kernel! And it seems gcc already supports that: https://gcc.gnu.org/onlinedocs/gcc-4.2.1/gcc/Code-Gen-Options.html -ffixed-x18 (found here: http://lists.denx.de/pipermail/u-boot/2013-September/162241.html) And we can initialize it similar to what we do on ARM -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=38719 --- Comment #2 from Anastasius Focht <focht(a)gmx.net> --- Hello André, unfortunately it's the 64-bit ELF loader that trashes register X18 during symbol resolving. --- snip --- (gdb) bt #0 0x0000007fb7fd9498 in do_lookup_x () from /lib/ld-linux-aarch64.so.1 #1 0x0000007fb7fd9de8 in _dl_lookup_symbol_x () from /lib/ld-linux-aarch64.so.1 #2 0x0000007fb7fdd7ec in _dl_fixup () from /lib/ld-linux-aarch64.so.1 #3 0x0000007fb7fe3b4c in _dl_runtime_resolve () from /lib/ld-linux-aarch64.so.1 #4 0x0000007fb7e2674c in default_dbg_vlog (cls=<optimized out>, channel=<optimized out>, func=<optimized out>, format=0x7fb7c39518 "TEB %p\n", args=...) at ../../../libs/wine/debug.c:414 #5 0x0000007fb7e26904 in wine_dbg_log (cls=__WINE_DBCL_ERR, channel=<optimized out>, func=<optimized out>, format=<optimized out>) at ../../../libs/wine/debug.c:256 #6 0x0000007fb7c1a578 in signal_init_thread (teb=0x7fb7e18000) at ../../../dlls/ntdll/signal_arm64.c:815 #7 0x0000007fb7c1fb54 in thread_init () at ../../../dlls/ntdll/thread.c:299 #8 0x0000007fb7bfc29c in __wine_process_init () at ../../../dlls/ntdll/loader.c:3105 #9 0x0000007fb7e27c50 in wine_init (argc=2, argv=0x7ffffff4e8, error=0x7fffffefa0 "", error_size=1024) at ../../../libs/wine/loader.c:958 #10 0x0000000000400c8c in main (argc=2, argv=0x7ffffff4e8) at ../../loader/main.c:247 (gdb) info share
From To Syms Read Shared Object Library 0x0000007fb7fd1b80 0x0000007fb7fe7d10 Yes (*) /lib/ld-linux-aarch64.so.1 0x0000007fb7e24830 0x0000007fb7e2bbb4 Yes /root/wine/64/loader/../libs/wine/libwine.so.1 0x0000007fb7dea470 0x0000007fb7df7450 Yes (*) /lib64/libpthread.so.0 0x0000007fb7ca08c0 0x0000007fb7d8215c Yes (*) /lib64/libc.so.6 0x0000007fb7c6ee10 0x0000007fb7c6fa00 Yes (*) /lib64/libdl.so.2 0x0000007fb7bd0490 0x0000007fb7c2bf64 Yes /root/wine/64/dlls/ntdll/ntdll.dll.so 0x0000007fb7aef2a0 0x0000007fb7b3aa00 Yes (*) /lib64/libm.so.6
(gdb) frame 6 #6 0x0000007fb7c1a578 in signal_init_thread (teb=0x7fb7e18000) at ../../../dlls/ntdll/signal_arm64.c:815 815 ERR("TEB %p\n", teb); (gdb) p teb $1 = (TEB *) 0x7fb7e18000 (gdb) frame 0 #0 0x0000007fb7fd9498 in do_lookup_x () from /lib/ld-linux-aarch64.so.1 (gdb) info r x0 0x7fb7e20ad2 548545891026 x1 0x8d9b5656 2375767638 x2 0x7fffffe9d0 549755808208 x3 0x7fb7e20708 548545890056 x4 0x7fffffe9e0 549755808224 x5 0x7fb8000418 548547855384 x6 0x0 0 x7 0x7fb7ff9078 548547825784 x8 0x0 0 x9 0x7a08a15e8d9b5656 8793455699915658838 x10 0x7fb7e20ae1 548545891041 x11 0x7fb7ff9078 548547825784 x12 0x7fffffe954 549755808084 x13 0x7fffffe958 549755808088 x14 0x7fffffea20 549755808288 x15 0x7fb7e1f9ac 548545886636 x16 0x7fb7fceff8 548547653624 x17 0x7fb7fe3b08 548547738376 x18 0x7fb7e18000 548545855488 x19 0x7fb7ffba90 548547836560 x20 0x1 1 x21 0x7fffffea78 549755808376 x22 0x0 0 x23 0x7fb7e20ad2 548545891026 x24 0x7fb7ff9078 548547825784 x25 0x7fb7ffb738 548547835704 x26 0x1 1 x27 0x8d9b5656 2375767638 x28 0x7fffffe9d0 549755808208 x29 0x7fffffe810 549755807760 x30 0x7fb7fd9de8 548547698152 sp 0x7fffffe7f0 0x7fffffe7f0 pc 0x7fb7fd9498 0x7fb7fd9498 <do_lookup_x+32> cpsr 0x40000000 1073741824 fpsr 0x0 0 fpcr 0x0 0 --- snip --- --- snip --- (gdb) disas Dump of assembler code for function do_lookup_x: 0x0000007fb7fd9478 <+0>: sub sp, sp, #0x120 0x0000007fb7fd947c <+4>: stp x29, x30, [sp,#32] 0x0000007fb7fd9480 <+8>: add x29, sp, #0x20 0x0000007fb7fd9484 <+12>: stp x23, x24, [sp,#80] 0x0000007fb7fd9488 <+16>: stp x19, x20, [sp,#48] 0x0000007fb7fd948c <+20>: stp x27, x28, [sp,#112] 0x0000007fb7fd9490 <+24>: stp x21, x22, [sp,#64] 0x0000007fb7fd9494 <+28>: stp x25, x26, [sp,#96] 0x0000007fb7fd9498 <+32>: ldr w23, [x5,#8] 0x0000007fb7fd949c <+36>: str x0, [x29,#224] 0x0000007fb7fd94a0 <+40>: mov x24, x1 0x0000007fb7fd94a4 <+44>: mov x14, x2 0x0000007fb7fd94a8 <+48>: str x3, [x29,#184] 0x0000007fb7fd94ac <+52>: str x4, [x29,#216] 0x0000007fb7fd94b0 <+56>: mov x20, x6 0x0000007fb7fd94b4 <+60>: mov x11, x7 ... 0x0000007fb7fd9540 <+200>: ldr x18, [x2,#8] ; dang 0x0000007fb7fd9544 <+204>: cbz x3, 0x7fb7fd9b28 <do_lookup_x+1712> ... 0x0000007fb7fd9668 <+496>: add x5, x18, x5, lsl #3 ; dang 0x0000007fb7fd966c <+500>: mov w6, w16 0x0000007fb7fd9670 <+504>: str x19, [sp] 0x0000007fb7fd9674 <+508>: str x8, [x29,#128] 0x0000007fb7fd9678 <+512>: str x9, [x29,#104] 0x0000007fb7fd967c <+516>: str x10, [x29,#152] 0x0000007fb7fd9680 <+520>: str x11, [x29,#136] 0x0000007fb7fd9684 <+524>: str x12, [x29,#112] 0x0000007fb7fd9688 <+528>: str x13, [x29,#120] 0x0000007fb7fd968c <+532>: str x14, [x29,#144] 0x0000007fb7fd9690 <+536>: str x15, [x29,#176] 0x0000007fb7fd9694 <+540>: str x16, [x29,#168] 0x0000007fb7fd9698 <+544>: str x18, [x29,#160] ; dang ... 0x0000007fb7fd96c4 <+588>: ldr x16, [x29,#168] 0x0000007fb7fd96c8 <+592>: ldr x18, [x29,#160] ; dang ... 0x0000007fb7fd9b60 <+1768>: cbz w16, 0x7fb7fd96d8 <do_lookup_x+608> 0x0000007fb7fd9b64 <+1772>: mov w0, #0x18 ; dang 0x0000007fb7fd9b68 <+1776>: umull x5, w16, w0 ... 0x0000007fb7fd9b8c <+1812>: add x5, x18, x5 ; dang 0x0000007fb7fd9b90 <+1816>: mov w6, w16 ... 0x0000007fb7fd9bb8 <+1856>: str x18, [x29,#160] ; dang 0x0000007fb7fd9bbc <+1860>: bl 0x7fb7fd92d8 <check_match> 0x0000007fb7fd9bc0 <+1864>: mov x25, x0 0x0000007fb7fd9bc4 <+1868>: ldr x8, [x29,#128] 0x0000007fb7fd9bc8 <+1872>: ldr x9, [x29,#104] 0x0000007fb7fd9bcc <+1876>: ldr x10, [x29,#152] 0x0000007fb7fd9bd0 <+1880>: ldr x11, [x29,#136] 0x0000007fb7fd9bd4 <+1884>: ldr x12, [x29,#112] 0x0000007fb7fd9bd8 <+1888>: ldr x13, [x29,#120] 0x0000007fb7fd9bdc <+1892>: ldr x14, [x29,#144] 0x0000007fb7fd9be0 <+1896>: ldr x16, [x29,#168] 0x0000007fb7fd9be4 <+1900>: ldr x18, [x29,#160] ; dang 0x0000007fb7fd9be8 <+1904>: cbz x0, 0x7fb7fd9b58 <do_lookup_x+1760> ... 0x0000007fb7fd9ce4 <+2156>: b 0x7fb7fd9b48 <do_lookup_x+1744> --- snip --- A safe solution would be to rebuild the aarch64 toolchain with '-ffixed-x18' enabled by default along with glibc (or better whole userland). Regards -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=38719 --- Comment #3 from André H. <nerv(a)dawncrow.de> --- (In reply to Anastasius Focht from comment #2)
Hello André,
unfortunately it's the 64-bit ELF loader that trashes register X18 during symbol resolving.
...
A safe solution would be to rebuild the aarch64 toolchain with '-ffixed-x18' enabled by default along with glibc (or better whole userland).
Maybe safe, but also very user unfriendly as long as it's not upstream... -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=38719 --- Comment #4 from Anastasius Focht <focht(a)gmx.net> --- Hello André, --- quote --- Maybe safe, but also very user unfriendly as long as it's not upstream... --- quote --- Well, I think we're still in a comfortable situation here since distros with aarch64 support are not that widespread yet and the user base is quite small. What needs to be done is to reach out major distros (starting with Suse), explaining the situation and ask for their support to implement/deploy the fix. Regards -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=38719 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|64-bit ARM Windows |64-bit ARM Windows |applications from Windows |applications from Windows |SDK for Windows 10 crash |SDK for Windows 10 crash |when accessing TEB/PEB |when accessing TEB/PEB |members (AArch64 platform |members (AArch64 platform |specific register X18 used |specific register X18 must |for TEB?) |be reserved for TEB) --- Comment #5 from Anastasius Focht <focht(a)gmx.net> --- Hello folks, I've refined the summary in case it's referred to in mailing lists (distros, libc). Example 'ld-linux-aarch64.so.1' (which is 'ld-2.19-2014.08-1-git.so'), taken from my Linaro aarch64-linux-gnu 4.9 cross toolchain (Linux x86_64 host) Following X18 references: --- snip --- 0000000000006790 _dl_rtld_di_serinfo::add_path MOV X19, X18 0000000000007E94 _dl_rtld_di_serinfo MOV X18, X21 0000000000007EB8 _dl_rtld_di_serinfo MOV X18, X21 0000000000007F44 _dl_rtld_di_serinfo MOV X18, X21 0000000000007F94 _dl_rtld_di_serinfo MOV X18, X21 0000000000007FA4 _dl_rtld_di_serinfo MOV X18, X21 0000000000008048 do_lookup_x::check_match LDR W2, [X18,#0x3C] 000000000000806C do_lookup_x::check_match LDR X0, [X18,#0x28] 0000000000008070 do_lookup_x::check_match OV X20, X18 0000000000008080 do_lookup_x::check_match LDR X2, [X18,#0x20] 0000000000008084 do_lookup_x::check_match LDR X1, [X18,#0x18] 000000000000853C do_lookup_x MOV X18, X23 00000000000086B0 do_lookup_x MOV X18, X23 0000000000015168 _dl_tlsdesc_dynamic STP X17, X18, [SP,#0xA0+var_40] 0000000000015210 _dl_tlsdesc_dynamic LDP X17, X18, [SP,#0xA0+var_40] 0000000000015240 _dl_tlsdesc_resolve_rela STP X17, X18, [SP,#0xA0+var_10] 00000000000152F8 _dl_tlsdesc_resolve_rela LDP X17, X18, [SP,#0xA0+var_10] 0000000000015330 _dl_tlsdesc_resolve_hold STP X17, X18, [SP,#0xB0+var_10] 00000000000153EC _dl_tlsdesc_resolve_hold LDP X17, X18, [SP,#0xB0+var_10] --- snip --- No special treatment, it's really used as general purpose register. The _dl_tlsdesc* X18 references result from NSAVEXREGPAIRS macro usage: https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/aarch64/dl-tlsdesc.... Regards -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=38719 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |aa139d3e86402ea98fc930d9fc7 | |8634b1c000700 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Anastasius Focht <focht(a)gmx.net> --- Hello folks, the Wine part is committed here: https://source.winehq.org/git/wine.git/commitdiff/aa139d3e86402ea98fc930d9fc... Do we need another 'upstream' bug to care for distros (toolchain, userland)? Regards -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=38719 --- Comment #7 from André H. <nerv(a)dawncrow.de> --- (In reply to Anastasius Focht from comment #6)
Hello folks,
the Wine part is committed here: https://source.winehq.org/git/wine.git/commitdiff/ aa139d3e86402ea98fc930d9fc78634b1c000700
Do we need another 'upstream' bug to care for distros (toolchain, userland)?
I'd say yes -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=38719 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.winehq.org/sho | |w_bug.cgi?id=38780 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=38719 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #8 from Alexandre Julliard <julliard(a)winehq.org> --- Closing bugs fixed in 1.7.46. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=38719 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- URL|http://go.microsoft.com/fwl |https://web.archive.org/web |ink/p/?LinkId=536682 |/20200915210324/http://down | |load.microsoft.com/download | |/6/3/B/63BADCE0-F2E6-44BD-B | |2F9-60F5F073038E/standalone | |sdk/SDKSETUP.EXE -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (2)
-
wine-bugs＠winehq.org -
WineHQ Bugzilla