mirror of
https://github.com/hrydgard/ppsspp.git
synced 2026-08-31 17:55:23 +02:00
Homebrew commonly ships its unstripped ELF next to the EBOOT, which is already how the symbol loader turns z_un_08841f98 into a function name. That same ELF carries a DWARF .debug_line section, so the addresses can be mapped to source files and lines too - and a backtrace stops being four hex numbers: 08841f98 move sp,fp mesh.zig:163 0883afa4 li v0,0x0 MenuState.zig:821 088260d8 andi at,v0,0xFFFF State.zig:40 0882a27c andi at,v0,0xFFFF engine.zig:468 Surfaced in three places: per frame in hle.backtrace, in the "hit" object that cpu.breakpoint.hit and cpu.stepping share, and appended to the disassembly window's status bar. The breakpoint case keys on the pc rather than the address, since for a memory breakpoint the useful source location is the instruction that did the access, not the data it touched. Storage is a plain sorted table of absolute addresses per module. SymbolMap keeps module-relative addresses because its .ppsym files are meant to be reloaded by a different game that pulls in the same module; none of this is ever written anywhere - it's regenerated from the ELF each boot - so there'd be nothing for relative addresses to buy. Each module owns its own rows and file names outright and is keyed the way SymbolMap::UnloadModule is, so unloading one module drops its lines and nobody else's. The subtle part is end-of-sequence markers. Without them a lookup for an address in a gap - a compilation unit built without debug info - confidently reports the last line of an unrelated file. A prototype run over one test binary mis-attributed 70 of its 349 functions that way, so sequence ends are recorded as rows with line 0 and a lookup landing on one reports nothing instead. DWARF 2 through 4 are decoded (psp-gcc emits 2, Zig 4). Version 5 re-encoded the file table, so those units are skipped with a warning rather than mis-parsed - nothing targeting the PSP produces it today. Scope, since it's narrower than it sounds: PRX conversion strips every .debug section. I checked all 437 pspautotests .prx and CrossCraft's own app.prx - none have any. Of 24 installed homebrew EBOOTs, zero carry debug info; CrossCraft only does because it ships app.elf separately. So this helps someone developing homebrew, and does nothing at all for a commercial game. Costs about 1.2 MB for a large Zig binary (98383 rows, 438 files) and nothing for anything without debug info. Follows bAutoSaveLoadSymbols like the symbols do. pspautotests 314/314, UnitTest 55/55, CoreUWP builds. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GZq8ZtJmFY7bkX5FVkr3P9
================================================================ NOTE: These are legacy instructions for building using ndk-build. We mostly only use this on CI because it's faster than gradle. There might also be some holdouts around still using eclipse. ================================================================ First, build the C++ static library: > cd android > ./ab.sh Or > ./ab.cmd as appropriate. Start Eclipse, import the android directory as an existing project You need to also load the "native" project into your eclipse workspace Build and run. If you modify the C++ code, you need to rebuild the static library, of course. To get Eclipse to understand that you have in fact changed something if you haven't also changed any Java code, just add a space character to PPSSPPActivity.java, or right click the project and choose Refresh, and then relaunch the app on the device. A real Android device is strongly recommended for testing. Don't trust the emulator.