Running ps5-payload-dev SDK homebrew (websrv: Quake, Mari0): proposal, with a working Quake prototype

[karimibrahim07]

Summary

Homebrew built with the ps5-payload-dev SDK for the websrv launcher (Quake #6698, Mari0 #6239) can't run on AnyPS5 today. I got Quake to its main menu on Windows, with the attract demo running at about 25 FPS in software OpenGL. That run used three open PRs, one ready branch and some local binary patches. This thread proposes how to turn the patches into generic support, and asks which approach the maintainers want before I write it.

What already exists as PRs

Stop	Change
457 unresolved ELF import (plain names, .sprx dependencies)	#6697
weak imports of a bundled .so stop the title on Windows	#6702 (Windows side of #6080)
qsort_s missing	#6707
application heap: process metadata is missing (no PT_SCE_PROCPARAM)	branch fix/libc-heap-without-process-parameters, not opened yet: the relinker records "no parameters" and the heap uses its default allocator

What the prototype still patched by hand

These apps don't start like a PS5 executable. The SDK's _start → __crt_start expects the launcher's payload_args_t: sys_dynlib_dlsym, kernel r/w pipes and kdata_base. It sets up kernel access, patches the kernel and runs the SDK's own runtime linker (__rtld_*), which loads .sprx and .so files itself. AnyPS5 can't provide kernel access, but AnyPS5 has already loaded and bound everything by the time the entry point runs. So the prototype skipped that part:

1. Entry. _start was replaced by a call to main(argc, argv, envp). Quake's .init_array is empty, so no constructor was lost. In general, DT_INIT and DT_INIT_ARRAY would have to run first, as the SDK's __rtld_lib_init does.
2. No param.json. AppMetadata throws param.json not found. The prototype used a minimal one.
3. The SDK's private loader. SDL loads libOSMesa.so.8 with the SDK's __dlopen and __dlsym, which are linked into quake.elf. OSMesa's own weak __dlopen, __dlsym, __dladdr, __dlclose and __dlerror imports expect them too. The prototype made them jump to AnyPS5's dlopen, dlsym and dlerror.
4. Re-opening a bundled module. dlopen("libOSMesa.so.8") resolves against the working directory, and a second copy of a guest module has unbound imports. The prototype made the path reach the instance that was already loaded.
5. Inline syscalls. OSMesa's statically linked SDK mmap and mprotect are raw syscall sequences. --trap-sdk-syscall-stubs turns them into UD2. The prototype redirected them to AnyPS5's mmap and mprotect.

Questions

• Detecting these programs. They have ET_DYN (not 0xfe10), no PT_SCE_PROCPARAM, and the SDK's payload_get_args, __crt_start and __rtld_* symbols. Is keying on SDK symbol names acceptable, given that they're only in .symtab and a stripped payload loses them? Or should it be an explicit option such as --payload-entry?
• Entry and loader (1, 3). Should the relinker start these at main after running their initializers, and bind the SDK's __dl* functions to libkernel's dlopen family? Or would you rather emulate payload_args_t with a working sys_dynlib_dlsym and leave the kernel parts failing?
• Module lookup (4). Should dlopen of a bare name (or of an already-loaded bundled module's soname) return that module, as the SDK's rtld does with LD_LIBRARY_PATH (which homebrew.js sets to the app folder)?
• Raw syscalls (5). Should the trap handler emulate the few trapped SDK syscalls (mmap 477, mprotect 74), or is that out of scope?

If the direction is agreed, I'd send each step as its own PR with tests, keeping Quake (#6698) as the evidence.

Setup

Windows 11 Pro (26300), RTX 3060, WinLibs GCC 15.2.0 r7, Release, main 5d9dcc42d + #6697 + #6702 + #6707 + the heap branch. q1.7z SHA-256 9692254071d5a90b5f4d7fb316960ae1f4e586f944eb1d4641a79a914fd834fb.

AI-assisted.

[johnmaia]

A data point for choosing between the approaches: ps5-payload-dev SDK homebrew packaged as an app already takes AnyPS5's normal path. On 2026-10-09 I built EVO-PLAYER (PPSA99039, sainsaji/EVO-PLAYER-PS5 v0.11.0) from source with SDK v0.42. Its scripts/package-app.sh produces eboot.bin + sce_module/libc.prx + sce_sys. After unwrapping the fake-signed SELFs, the relinker converts it like a retail title. It loads, binds its imports by NID and runs into its own feature stops (it reached Videodec2 and then RmlUi's AGC init), with no payload_args_t, __rtld_* or private dlopen handling needed. One detail from that run: its libc.prx is a placeholder shim, so it must not be excluded with --exclude-sce-module, because its real libc imports still need AnyPS5's libc.

So for titles whose sources are available, packaging them as an app sidesteps most of the "what the prototype still patched" list. Payload-only builds such as websrv still need the generic support you propose. I haven't tried Quake or Mari0 either way.

AI-assisted: yes (Claude Code)

[karimibrahim07]

Thanks, that's a useful split. Where the source is available, packaging as an app avoids the payload path entirely. The Quake build here is only released as a websrv payload (homebrew.js + quake.elf), so it still needs the generic support. Building it as an app could be a way to confirm that the rest of Quake (SDL, OSMesa, audio) works on the normal path, separately from the payload questions.