memory: Dehardcode the use of fixed memory range constants

The locations of these can actually vary depending on the address space
layout, so we shouldn't be using these when determining where to map
memory or be using them as offsets for calculations. This keeps all the
memory ranges flexible and malleable based off of the virtual memory
manager instance state.

1 files changed, 2 insertions, 1 deletions

diff --git a/src/core/hle/kernel/thread.cpp b/src/core/hle/kernel/thread.cpp
index 315f65338..064ed908d 100644
--- a/src/core/hle/kernel/thread.cpp
+++ b/src/core/hle/kernel/thread.cpp
@@ -262,8 +262,9 @@ SharedPtr<Thread> SetupMainThread(KernelCore& kernel, VAddr entry_point, u32 pri
     SetCurrentPageTable(&owner_process.vm_manager.page_table);
 
     // Initialize new "main" thread
+    const VAddr stack_top = owner_process.vm_manager.GetTLSIORegionEndAddress();
     auto thread_res = Thread::Create(kernel, "main", entry_point, priority, 0, THREADPROCESSORID_0,
-                                     Memory::STACK_AREA_VADDR_END, &owner_process);
+                                     stack_top, &owner_process);
 
     SharedPtr<Thread> thread = std::move(thread_res).Unwrap();