Added KernelModuleAddressDescription() (Core/HLE/sceKernelModule.cpp),
which looks up which currently loaded module (and text/data/bss/segment
section within it) an address falls in, e.g. "EBOOT.BIN.text+1234".
Wired it into:
- Core_MemoryException/Core_ExecException/Core_BreakException
(Core/Core.cpp), appended next to every address/pc/ra shown in their
log lines.
- FormatStackTrace (Core/MemFault.cpp), appended per-frame next to the
existing symbol description.
This makes crash/exception logs actionable even when there's no symbol
at the faulting address - you at least get which module and section
it's in, useful for reverse engineering unfamiliar code.
Verified live via headless: injected a MIPS break instruction at the
current PC (through Tools/wsdbg) and confirmed the log line changed from
"break instruction hit at 088040ac" to "break instruction hit at 088040ac
[sceDisplayWaitVblank Test.text+ac]".
Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01XDNwPPuidmNxQGRJxBuRL6
Reordered main() to: g_Config.RestoreDefaults() -> headless's own hardcoded
overrides for deterministic test execution -> cmdLineOptions.ApplyToConfig()
-> CoreParameter setup -> launch. Previously ApplyToConfig() ran first and
got silently overwritten by both RestoreDefaults() and the hardcoded
overrides, so no command-line flag touching a g_Config setting actually took
effect for a real run (this is what required the "set iRemoteISOPort again"
workaround for --debugger=PORT, now removed).
The two hardcoded lines that used to read coreParameter.renderScaleFactor/
gpuCore now compute the same values directly from cmdLineOptions/glWorking/
gpuCore instead, since CoreParameter is no longer built yet at that point -
it's now constructed after ApplyToConfig(), which is what let those two
comments' "above"/"below" wording get corrected too.
Verified: --debugger=PORT still binds the exact requested port and pauses
the CPU, and a normal --compare test run (cpu_alu) still passes.
Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01XDNwPPuidmNxQGRJxBuRL6
Reflect the CmdLine.cpp unification and the headless net::Init() fix in
docs/WebSocketDebugger.md and AGENTS.md - previously these described the
app-only boolean --debugger flag and flagged headless as unreliable.
Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01XDNwPPuidmNxQGRJxBuRL6
The headless build's own --debugger=PORT never actually worked on
Windows: headless/Headless.cpp never called net::Init() (WSAStartup),
so socket binding silently failed ("Unable to listen on any port
(debugger - webserver)"). Fixed by calling net::Init()/net::Shutdown()
there, gated on --debugger being passed since headless has no other use
for networking.
With that confirmed working, move parsing into the shared
Core/CmdLine.cpp auto-param table as a single --debugger=PORT option
(0 = pick automatically) available on both CmdLineMode::Application and
CmdLineMode::Headless, replacing the previous app-only boolean
--debugger flag and headless's separate ad hoc argv scan for it.
Behavior differs deliberately by build, same as before:
- App: just starts the debugger, game boots and runs normally.
- Headless: also forces coreParameter.startBreak = true (break before
anything runs), as it always has. Headless re-applies iRemoteISOPort
after its own g_Config.RestoreDefaults() call, which runs after
ApplyToConfig() and would otherwise wipe the requested port.
Verified live: headless now binds the requested port and responds to
cpu.status/game.status; the app build binds the requested port and
runs the game normally (not paused).
Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01XDNwPPuidmNxQGRJxBuRL6
Henrik Rydgård
a-blondel
Kevin Reinholz