mirror of
https://github.com/hrydgard/ppsspp.git
synced 2026-09-03 19:25:18 +02:00
Homebrew almost always ships the ELF it was built from alongside the EBOOT - app.elf next to app.prx - but prxgen strips the symbol table on the way to the PRX, so the module PPSSPP loads has no names at all and MIPSAnalyst calls every function it finds z_un_<address>. Working out what any of them are meant hand- parsing that ELF with a throwaway script, which is how the CrossCraft relocation bug got identified. So read it directly. On module load, scan the game's own directory for an ELF with a symbol table and add its STT_FUNC/STT_OBJECT entries at the module's base. CrossCraft picks up 3734 symbols, and the disassembly turns from z_un_088c00f0 into world.init_empty, with static_allocator.alloc at the vtable entry it calls - the two functions that took the longest to identify by hand. Matching is the part worth getting right, since a wrong match puts confident nonsense at real addresses, which beats having no names only in the sense that it's worse. A candidate has to be a 32-bit ELF with a symbol table whose highest section ends within a page of the loaded module's size - the companion links at base 0 and covers the same image, so that's a tight check, and unrelated ELFs sitting in the same folder fail it. Symbols outside the module are skipped individually too. Names go in with updateName, so they win over the analyzer's placeholders rather than losing to whichever got there first. Gated on the existing bAutoSaveLoadSymbols setting (off by default), which already means "keep symbol names around for me" and avoids a directory scan per module load otherwise. pspautotests 314/314. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GZq8ZtJmFY7bkX5FVkr3P9