A converted game fails at launch on the first system function that no
built library exports, one function per run. tools/import_audit.py reads
the registry written by relinker --registry and classifies every imported
NID in one pass:
- implemented: a built library exports it
- stub: exported, but the whole function calls NotImplemented_nid_no_patch
- absent: no built library exports it, so the loader fails
- module: the import names a file the title ships itself
Exports are read from the built .prx files (ELF dynsym and PE export
table), the same view the loader has. Stubs come from the source tree
through tools/progress.py, and NIDs through tools/nid_names.py. The report
also lists needed libraries without a file and imports found only in a
different library than the one they name. --names adds names from an
aerolib.csv file and never downloads one; --json writes the full result
stamped with the repository commit.
The test builds ELF and PE libraries byte by byte, checks that every
reference lands in exactly one class, and pins the NID of
sceMsgDialogProgressBarSetValue (wTpfglkmv34) as an external anchor.
Registered in CTest as import_audit.
The segment filter dropped every header in the PT_LOOS..PT_HIOS range,
which includes PT_GNU_EH_FRAME. The unwinders find the executable's
unwind tables through that header, so no C++ exception thrown in the
main executable could be caught on Linux.
The header is kept only when the output program header table still fits
in the input's table; otherwise it is dropped as before, with a warning.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01HeC9bA3n74TzJRYv9AgBE8
The retry that waits for a target to leave NtContinue, NtContinueEx or
libwinpthread-1.dll had no bound, so a target that stayed there made
sceKernelRaiseException spin forever. It now throws after 1 s. A new
guest_raise_exception phase keeps a thread inside NtContinue by
continuing a context that calls NtContinue again, and checks that the
raise throws and that the handler did not run.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
The console's DCC of a single-level 4-byte SW_64KB_R_X surface is
ceil(W/512) * ceil(H/512) * 4096 bytes, 49152 for 1920x1080, but the
driver stored and read one key per 256 surface bytes (34560).
PPSA26344 retiles its render DCC into the displayable copy it
registers (cs_dcc_retile_32bpp); a retile of the stale tail gives the
mixed keys PPSA12544 stops on.
DccKeyCount gives that extent. Color target and storage image key
stores cover it when the DCC is pipe-aligned (CB_COLOR_ATTRIB3 bit 30,
T# word 6 bit 19), whose CB keys reach its last meta block, and throw
where it is not writable; unaligned DCC keeps one key per 256 bytes,
as do texture and color target key reads. DisplayBufferKeys reads the
display DCC over the extent, presents only when every key agrees,
names the first differing key's pixels and checks a pending image
against those keys.
Mode 0 of CB_COLOR_CONTROL turns color writes off, but a draw with a
written color target and this mode was skipped as unsupported. Count no
export as written when the mode is disable, so the draw renders without
a color attachment like the existing attachment-free path, and accept
the mode with any ROP3, which does not apply while writes are off.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
boykopovar