diff options
Diffstat (limited to 'winsup/cygwin/wow64.cc')
| -rw-r--r-- | winsup/cygwin/wow64.cc | 33 |
1 files changed, 10 insertions, 23 deletions
diff --git a/winsup/cygwin/wow64.cc b/winsup/cygwin/wow64.cc index f91a6d855..fcfa58ec2 100644 --- a/winsup/cygwin/wow64.cc +++ b/winsup/cygwin/wow64.cc @@ -8,6 +8,10 @@ This software is a copyrighted work licensed under the terms of the Cygwin license. Please consult the file "CYGWIN_LICENSE" for details. */ +#ifndef __x86_64__ +/* WOW64 only plays a role in the 32 bit version. Don't use any of this + in the 64 bit version. */ + #include "winsup.h" #include "cygtls.h" #include "ntdll.h" @@ -37,15 +41,8 @@ wow64_eval_expected_main_stack (PVOID &allocbase, PVOID &stackbase) stack address on Vista/2008 64 bit is 0x80000 and on W7/2K8R2 64 bit it is 0x90000. However, this is no problem because the system sticks to that address for all WOW64 processes, not only for the first one - started from a 64 bit parent. - - On 64 bit W10 1511 the stack starts at 0x400000 by default. See comment - in wow64_test_for_64bit_parent. */ -#ifdef __x86_64__ - allocbase = (PVOID) 0x400000; -#else + started from a 64 bit parent. */ allocbase = (PVOID) 0x30000; -#endif /* Stack size. The OS always rounds the size up to allocation granularity and it never allocates less than 256K. */ size = roundup2 (ntheader->OptionalHeader.SizeOfStackReserve, @@ -79,14 +76,6 @@ wow64_test_for_64bit_parent () process here. If so, we note this fact in wow64_needs_stack_adjustment so we can workaround the stack problem in _dll_crt0. See there for how we go along. */ - - /* Amazing but true: Starting with Windows 10 1511 this problem has been - reintroduced, just in the opposite direction: If a 64 bit process is - created from a 32 bit WOW64 process, the main thread stack in the 64 - bit child gets moved to another location than the default. In the - forked child, the stack is back where it usually is when started from - another 64 bit process. Therefore we have to be able to recognize - this scenarion now on 64 bit as well. We I don't believe it... */ NTSTATUS ret; PROCESS_BASIC_INFORMATION pbi; HANDLE parent; @@ -118,8 +107,6 @@ wow64_test_for_64bit_parent () return !wow64; } -#ifndef __x86_64__ - PVOID wow64_revert_to_original_stack (PVOID &allocationbase) { @@ -184,14 +171,12 @@ wow64_revert_to_original_stack (PVOID &allocationbase) accordingly, and return the new, 16 byte aligned address for the stack pointer. The second half of the stack move is done by the caller _dll_crt0. */ - NtCurrentTeb()->Tib.StackBase = (char *) newbase; - NtCurrentTeb()->Tib.StackLimit = (char *) newtop; + NtCurrentTeb ()->Tib.StackBase = (char *) newbase; + NtCurrentTeb ()->Tib.StackLimit = (char *) newtop; _main_tls = &_my_tls; - return PTR_ADD (NtCurrentTeb()->Tib.StackBase, -16); + return PTR_ADD (NtCurrentTeb ()->Tib.StackBase, -16); } -#endif /* !__x86_64__ */ - /* Respawn WOW64 process. This is only called if we can't reuse the original stack. See comment in wow64_revert_to_original_stack for details. See _dll_crt0 for the call of this function. @@ -226,3 +211,5 @@ wow64_respawn_process () TerminateProcess (GetCurrentProcess (), ret); ExitProcess (ret); } + +#endif /* !__x86_64__ */ |