diff --git a/Core/HLE/HLETables.cpp b/Core/HLE/HLETables.cpp index d76e9eb3ac..94e15495e9 100644 --- a/Core/HLE/HLETables.cpp +++ b/Core/HLE/HLETables.cpp @@ -168,14 +168,7 @@ static const HLEFunction LoadCoreForKernel[] = { // sceKernelSm1ReferOperations() returns a pointer to a driver-registered "SM1 operations" // table (set up via the sibling sceKernelSm1RegisterOperations(), also unimplemented here), -// or NULL if nothing has registered one. Real callers (e.g. kd/lowio.prx) only check the -// return value against exactly zero before dereferencing it as a struct/vtable pointer - -// leaving this as a generic `nullptr` HLE table entry meant it fell through to the "function -// unimplemented" fallback, which returns SCE_KERNEL_ERROR_LIBRARY_NOT_YET_LINKED -// (0x8002013A) in v0 instead of 0. That error code isn't zero, so the caller's null check -// didn't catch it, and it went on to call through a function pointer read from an offset -// within that "structure" - really an unrelated error code - causing a wild read/jump. Since -// nothing currently registers real SM1 operations, returning NULL here is correct. +// or NULL if nothing has registered one. static u32 sceKernelSm1ReferOperations() { return hleLogDebug(Log::sceKernel, 0); } diff --git a/Core/HLE/sceKernel.cpp b/Core/HLE/sceKernel.cpp index ed561d6a2e..17e975722c 100644 --- a/Core/HLE/sceKernel.cpp +++ b/Core/HLE/sceKernel.cpp @@ -1027,18 +1027,7 @@ static int sceKernelLoadExecBufferVSHUsbWlan(int bufferSize, u32 bufferAddr, u32 return hleLogInfo(Log::sceKernel, 0); } -const HLEFunction LoadExecForKernel[] = -{ - // The first 5 entries below (up through sceKernelExitGame) are this array's original, - // pre-VSH-work content, in their original order - kept exactly where they were. Every entry - // added since must go after them, never inserted earlier in this table: the funcindex (this - // array position) gets baked directly into resolved-import syscall opcodes written into - // guest RAM (see GetSyscallOp() in HLE.cpp), which savestates capture verbatim, so inserting - // a new entry before an existing one shifts every later entry's index and silently corrupts - // any savestate taken after that entry was already resolved (see AGENTS.md). A previous - // version of this table's VSH additions violated this three separate times (shifting - // sceKernelLoadExecVSHMs2/0X28D0D249, sceKernelExitVSHKernel/0x6D302D3D, and - // sceKernelExitGame/0x05572A5F) - fixed by moving the new entries after them instead. +const HLEFunction LoadExecForKernel[] = { {0x4AC57943, &WrapI_I, "sceKernelRegisterExitCallback", 'i', "i", HLE_KERNEL_SYSCALL }, {0XA3D5E142, &WrapI_U, "sceKernelExitVSHVSH", 'i', "x", HLE_KERNEL_SYSCALL }, {0X28D0D249, &WrapI_CU, "sceKernelLoadExecVSHMs2", 'i', "sx" }, diff --git a/Core/HLE/sceKernelMemory.cpp b/Core/HLE/sceKernelMemory.cpp index 76166ff6bd..35bb0b977d 100644 --- a/Core/HLE/sceKernelMemory.cpp +++ b/Core/HLE/sceKernelMemory.cpp @@ -1679,7 +1679,7 @@ static u32 SysMemUserForUser_D8DE5C1E() { // free size, see sceKernelMaxFreeMemSize above) of the user memory partition. Was previously // an unconditional `return 0` - real callers doing size-based decisions (e.g. "is there enough // memory to enable feature X") would see 0 total memory instead of a real, sane value. -static u32 SysMemUserForUser_ACBD88CA() { +static u32 sceKernelTotalMemSize() { return hleLogDebug(Log::sceKernel, PSP_GetUserMemoryEnd() - PSP_GetUserMemoryBase()); } @@ -2116,7 +2116,7 @@ const HLEFunction SysMemUserForUser[] = { {0X358CA1BB, &WrapI_I, "sceKernelSetCompiledSdkVersion606", 'i', "i" }, {0XFC114573, &WrapI_V, "sceKernelGetCompiledSdkVersion", 'i', "" }, {0X2A3E5280, nullptr, "sceKernelQueryMemoryInfo", '?', "" }, - {0XACBD88CA, &WrapU_V, "SysMemUserForUser_ACBD88CA", 'x', "" }, + {0XACBD88CA, &WrapU_V, "sceKernelTotalMemSize", 'x', "" }, {0X945E45DA, &WrapU_V, "SysMemUserForUser_945E45DA", 'x', "" }, {0XA6848DF8, nullptr, "sceKernelSetUsersystemLibWork", '?', "" }, {0X6231A71D, nullptr, "sceKernelSetPTRIG", '?', "" }, diff --git a/Core/HLE/sceKernelModule.cpp b/Core/HLE/sceKernelModule.cpp index 0f96b062dc..aa752d5ee9 100644 --- a/Core/HLE/sceKernelModule.cpp +++ b/Core/HLE/sceKernelModule.cpp @@ -1495,7 +1495,10 @@ static PSPModule *__KernelLoadELFFromPtr(const u8 *ptr, size_t elfSize, u32 load module->nm.gp_value = modinfo->gp; strncpy(module->nm.name, modinfo->name, ARRAY_SIZE(module->nm.name)); - if (!strcmp(module->nm.name, "scePaf_Module")) { + if (equals(module->nm.name, "scePaf_Module")) { + // NOTE: This hackery is likely firmware-version-specific, so will need tweaking for + // other firmware versions than 6.61. + // // scePaf's own heap allocator expects a real memory-pool base address to already be // patched into this BSS slot before any of its code runs. Real hardware's loader (or // an early kernel init step) apparently does this - checked all 27 of scePaf's @@ -1515,7 +1518,9 @@ static PSPModule *__KernelLoadELFFromPtr(const u8 *ptr, size_t elfSize, u32 load } } - if (!strcmp(module->nm.name, "vsh_module")) { + if (equals(module->nm.name, "vsh_module")) { + // Like the above patch, this is likely firmware-version-specific. + // // vsh_module's SCE_VSH_GRAPHICS thread runs a scan over a small fixed table of // "alarm task" categories (2 categories, each with a count followed by that many // 4-byte item IDs). Category 0's data is legitimate, compiled-in content (count=8, diff --git a/Core/HLE/sceResmgr.cpp b/Core/HLE/sceResmgr.cpp index 5a7e833d76..67f805bc1c 100644 --- a/Core/HLE/sceResmgr.cpp +++ b/Core/HLE/sceResmgr.cpp @@ -17,8 +17,6 @@ #include -// MemMap.h first: PrxDecrypter.h's PSP_Header is written in u32_le and friends, and doesn't pull -// in the header that defines them. #include "Core/MemMap.h" #include "Core/Debugger/MemBlockInfo.h" #include "Core/ELF/PrxDecrypter.h" diff --git a/UWP/CoreUWP/CoreUWP.vcxproj b/UWP/CoreUWP/CoreUWP.vcxproj index 75b29f0a7d..e3a4523a23 100644 --- a/UWP/CoreUWP/CoreUWP.vcxproj +++ b/UWP/CoreUWP/CoreUWP.vcxproj @@ -167,6 +167,7 @@ + @@ -449,6 +450,7 @@ + diff --git a/UWP/CoreUWP/CoreUWP.vcxproj.filters b/UWP/CoreUWP/CoreUWP.vcxproj.filters index 918fc06cb4..bb2f5192e8 100644 --- a/UWP/CoreUWP/CoreUWP.vcxproj.filters +++ b/UWP/CoreUWP/CoreUWP.vcxproj.filters @@ -422,6 +422,7 @@ + @@ -706,6 +707,7 @@ +