PAC-MAN WORLD Re-PAC (PPSA06399) Boots and plays with Audio

[billythemenace2]

[Game bring-up] PAC-MAN WORLD Re-PAC (PPSA06399, Unity) on Windows, main 4f8d4017: boots and plays with four local changes; one relinker regression and one crash found

Result on main 4f8d4017 (11 Oct) plus the attached patch: the title boots, the title screen, menus and levels render correctly, audio works, and I completed a level. The run ended with an abort on the level-complete transition (item 3). No debug switches were set.

Short version for maintainers:

#	Finding	State
1	The Windows start-up stub no longer loads a needed library whose file name differs from the module name the imports declare, so the title stops with unresolved ELF import	Regression on main since 7755e1d05; small fix in the patch
2	Start-up stall: GC stop-the-world against a thread paused in host code	Not on main; local change in the patch (see #727)
3	A one-byte colour target placed on a freed stencil plane is still taken for the stencil plane	Not on main; #3277 does not cover it; not fixed in this patch
4	sceSysmoduleLoadModule ids 0x110 and 0x127 unknown	Not on main; #2541 names 0x110 as libSceNpTrophy2
5	Confirmed working on this title without any local help	#374 (depth clears through HTILE), #846 (--module-dir), #3173 (pipeline library module lifetime)

This is my second Unity IL2CPP title; the first was Silt (PPSA03306) in #2810.

Screenshots

Setup

Title	PAC-MAN WORLD Re-PAC, UP0700-PPSA06399_00-PACMANWORLDRE008,
Engine	Unity (IL2CPP), FMOD
AnyPS5	4f8d4017c7a4ce112e967b320478ec5d4450276f + the attached patch (10 files)
OS	Windows 11, build 10.0.26200
GPU	AMD Radeon RX 5700 XT, current Adrenalin driver as of 10 Oct 2026 (reports Vulkan 1.4.315)
Toolchain	MinGW-w64, Ninja

Layout next to eboot.elf: sce_module/ with the title's six system modules, Media/Modules/ (Il2CppUserAssemblies.prx, PS5Util.prx) and Media/Plugins/ (four Unity plugins).

relinker --windows --windows-diagnostics --registry --module-dir Media/Modules --module-dir Media/Plugins eboot.elf out\app.exe
app.exe

No APS5_* variables were set.

1. Relinker regression: a needed library is left out of the start-up load list

With an unmodified 4f8d4017 relinker the title stops before the window opens:

Loading PRX: C:\sonic\out\libs\libc.prx -> OK
FAIL: unresolved ELF import Gl6w5i0JokY
Searched libraries:
  ...
GetLastError: 127 - The specified procedure could not be found.

Gl6w5i0JokY is sceAppContentDownloadDataGetAvailableSpaceKb. libSceAppContent.prx is not in the searched list, and neither are libSceAudio3d.prx, libSceHmd.prx and libSceJson2.prx, all four of which were loaded for this title on 56fb1b3b.

The registry written by --registry shows 49 imports of the executable with no matched library:

Declared module (suffix)	Imports	Example	Needed file
#g#g	15	sceAjmBatchInitialize	libSceAjm.native.prx (loaded)
#W#W	22	sceAvPlayerAddSourceEx	libSceAvPlayer.native.prx (loaded)
#V#V	4	sceMsgDialogOpen	libSceMsgDialog.native.prx (loaded)
#X#X	8	sceAppContentInitialize	libSceAppContent.prx (not loaded)

My reading of WindowsEntryStubBuilder.cpp: since 87ca3a2cf a host library counts as imported from when its name up to the first dot equals a declared module name, and since 7755e1d05 a library that does not count is not loaded at all, where 8ebf89284 only skipped it when it was missing. The first three groups match by stem. The AppContent imports declare a module whose name is not libSceAppContent (I believe libSceAppContentUtil, but I did not read it out of the ELF), so the file that holds them is dropped and the unnamed imports, which search every loaded library, find nothing. The commit message of 87ca3a2cf mentions the same kind of mismatch for libSceJson and libSceJson2.prx, so other titles should be affected.

Change in the patch: if any declared module name matches no needed library by stem, every needed library is kept in the load list, because such an import may be in any of them. A missing library that nothing imports from is still skipped whenever all declared names do match. With the change the relinker-only build passes its 110 tests on Linux, and this title starts.

A better fix may be a table of module names that differ from their file names; I did not attempt that.

2. Start-up stall at 0 FPS (not on main)

Unchanged from what I measured on 56fb1b3b; Exception.cpp has not changed since. A timed all-thread dump showed the main thread in sceKernelWaitSema inside IL2CPP's GC, waiting for the other threads to acknowledge signal 30, and one thread parked here:

sceKernelLoadStartModule -> dlopen_nid_postfix+0xad -> ResolvePath_nid_no_patch+0x3d -> pthread_mutex_lock

RaiseOn had redirected another thread into its handler while that thread held Directories().mutex; the thread above then waited on that mutex in a non-alertable wait and never ran its own handler. Same shape as the WindowsMappings::mutex deadlock in #2810, and the case #727 warns about.

Local change (libkernel/System/src/Exception.cpp): when the suspended target's rip is outside guest code (the exe, the *.guest.prx images and the guest arena), RaiseOn resumes it and retries instead of redirecting it, for up to 2 s; if the thread is still at the same rsp after that it is redirected as before and a [signal] line is printed. That line has never appeared. The Windows condition-variable wait in Pthread/src/Cond.cpp re-takes its mutex by polling.

On 56fb1b3b: 4/5, 6/8 and 7/8 boots with earlier partial attempts, then 8/8 with this change. On main I have only booted with the change in place (both boots fine), so I have not re-measured the stall rate without it on main.

This is probably not the design #727 wants (interruptible waits). I am reporting it as evidence, with a dump available, rather than as the fix.

3. Abort on the level-complete transition: R8 colour target on a freed stencil plane (not on main, not fixed here)

[gpu] color target 0x24cdd0000 stays non-resident: AGC graphics: storage image access to depth/stencil surface 0x24cdd0000 is not implemented
[videoout] presentation failed: AGC graphics: sampling the stencil plane of depth surface 0x239e90000 (1920x1080, vk format 130)
as a 1920x1080 texture of guest format 1 (vk 9), tile mode 7, dimension 1, levels 0-0, slice 0 is not implemented
(T# 024cdd00 c0100000 010dc1df 91b00204 00000000 00700000 00000000 00000000)

Unity's render-texture pool freed a D32S8 target and gave the memory of its stencil plane to a 1920x1080 R8_UNORM colour target. #3277 lets a view fall through when its texel is not one byte wide; this one is one byte wide with the plane's extent, so it is still taken for the stencil plane, first as a colour target (pushed to the non-resident path) and then as a sampled texture (fatal).

The patch has a smaller change in the same area: cachedStorageTexture asks whether the view has the plane's extent and a texel the plane can hold (DepthSurfaceViewedBy) instead of DepthSurfaceAt(address). On 56fb1b3b that removed a fatal compute shader ...: storage image access to depth/stencil surface right after the menu. It does not help here, for the same reason #3277 does not.

No format test can separate these two. What I am trying next, not in this patch and not yet run: the last binder owns the memory. Binding a colour target over a depth surface's depth or stencil plane retires that surface for lookups until it is bound as a depth target again. The branches of #454 and #2519 look like they address surface retirement more thoroughly; I could not check their state.

Related: depth surfaces are never released. On 56fb1b3b a run ended after two levels with vkAllocateMemory depth target: Vulkan result -2, and a capture after one level listed 34 live depth surfaces, 32 of them 1920x1080 D32S8. On main this run reached 4244 MiB on the device-local heap (1778 MiB sampled textures and 642 MiB cached storage images accounted for) before the abort above ended it. I have not measured the depth surfaces' share, so the link is likely, not proven.

4. Unknown system module ids (not on main)

[libSceSysmodule/Export.cpp:140 sceSysmoduleLoadModule] unknown id: 272
[libSceSysmodule/Export.cpp:140 sceSysmoduleLoadModule] unknown id: 295

0x110 and 0x127. The call returns success and the title carries on. #2541 adds 0x110 as libSceNpTrophy2; I do not know what 0x127 is.

5. What worked on main without local help

• fix(agc): depth fast clears through the HTILE metadata #374, depth fast clears through HTILE. On 56fb1b3b this title rendered levels blown out to white with a missing sky, and black objects on the title screen, because it clears depth by zero-filling the HTILE with a toolkit fill kernel (0x30000 bytes for 1920x1080, 0x40000 for its 2048x2048 shadow atlas) followed by a rect-list draw that writes no depth. On main the picture is correct with no local change.
• feat(relinker): add --module-dir for modules loaded at run time #846, --module-dir. PSNCore.prx and SaveData.prx start when the title loads them; no copying into prx/ and no local relinker change needed.
• fix(agc): keep a shader library part's modules until the part is destroyed #3173, pipeline library module lifetime. On 56fb1b3b the background optimized link crashed in amdvlk64.dll (0xc0000005, amdvlk64.dll+0x21ee870) on the loading screen unless APS5_NO_PIPELINE_LTO=1 was set. On main, without the switch, this run went through eight level loads without it. One run, so encouraging rather than proven.

Other observations from this run

• Audio works: music and effects.
• Save data. A save from an earlier run mounted at start-up, and the title mounted, wrote and unmounted /savedata0 twice without an error. I did not verify the contents.
• Stutter with a cold shader cache. 535 shader-disk-cache misses and no hits over the session (every source change invalidates the cache). The watchdog line Wanted to force a call to sce::Agc::suspendPoint but not safe... repeated for up to 5 seconds during start-up while the first 169 shaders compiled.
• These notices appear a few times at scene changes and seem harmless:

  [gpu] storage image 0x22fbd0000: guest memory changed while GPU results were pending; keeping the CPU's blocks
  [gpu] storage image 0x227210000+0xc0000: memory no longer registered; 1 pending ranges dropped
  

• The title ships libc, libSceFace, libSceFaceTracker, libSceJobManager, libSceNpCppWebApi, libScePfs, PS5Util, Il2CppUserAssemblies and four Unity plugins itself. The relinker reported 1750 external references; with the fix in item 1 none is unresolved at start-up.

The attached patch

anyps5-pacman-repac-main-4f8d4017.patch, against 4f8d4017, 10 files. It is what this run used. Each row would be its own pull request:

Topic	Files
Keep every needed library when a declared module matches none (item 1)	relinker/elfpatcher/src/windows/WindowsEntryStubBuilder.cpp
Signal delivery to threads in host code (item 2)	libkernel/System/src/Exception.cpp, libkernel/Pthread/src/Cond.cpp
Mapping-table lock that names its holder (from #2810)	libc/include/WindowsMappings.hpp, libc/include/GuestArena.hpp, libc/src/GuestArena.cpp, libkernel/System/src/Exception.cpp
Storage access tests the view, not only the address (item 3, partial)	Graphics/src/DepthSurface.cpp, Graphics/include/DepthSurface.hpp, Graphics/src/ShaderResources.cpp
Crash report: stack candidates for threads with short backtraces	libc/src/specifics/windows/CrashReport.cpp

Notes

• Diagnosis and code changes were done with AI assistance (Claude); I ran every build and test on my own machine. The Windows-side code was syntax-checked but only exercised by these runs on one AMD GPU. The relinker tests were run on Linux.
  anyps5-pacman-repac-main-4f8d4017.patch