[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?)
wine-bugs at winehq.org
wine-bugs at winehq.org
Mon Jun 8 18:11:43 CDT 2015
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 at winehq.org
Reporter: focht at 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.html
("[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.
More information about the wine-bugs
mailing list