mirror of
https://github.com/hrydgard/ppsspp.git
synced 2026-08-31 17:55:23 +02:00
Henrik RydgårdandClaude Opus 5
3f0c2da5a9
Following on from the DWARF line table: the lookup was only reachable from hle.backtrace, the breakpoint hit object and the ImGui disassembly status bar. Now also in - the ImDebugger call stack (new Source column), - the Win32 call stack (new Source column), - the Win32 disassembly status bar, matching the ImGui one, - the ImDisasmView right-click menu, which showed a bare address as its heading and now leads with "mesh.zig:163 (08841f98)" when there's a line for it, - breakpoint log lines - a log-only breakpoint's entire output is those lines, and "BKP PC=08841f98 mesh.zig:163" reads a great deal better than an address when you're scanning a few thousand of them, - crash stack traces, via FormatStackTrace, which is what the crash screen and crash reporting both use. That last one is where it earns its keep, and it needed the invalid-jump path to produce a stack trace at all - it was the one exec exception that didn't. It's also the one that most deserves it: the address it jumped to tells you nothing, the callers tell you everything. Execution has already moved to the bad address by the time it's noticed, so a walk from pc finds no function to start from; WalkCurrentStack takes an explicit starting pc now, and falling back to ra recovers the chain. Reproducing the original CrossCraft bug: CPU Jump: Invalid jump to ae870000 from PC ae870000(invalid) RA 08841f98 MIPS call stack: rendering.mesh.Mesh(PspVertex).draw at mesh.zig:163 (08841c30+368, ...) state.MenuState.draw at MenuState.zig:821 (0883ab90+414, ...) engine.Engine.stepFrameInternal at State.zig:40 (08820f74+5164, ...) utils.module._module_main_thread at engine.zig:468 (088272c4+2fb8, ...) Fixed a pre-existing double-report while in there: every case in Core_ExecException sent its message and then fell through to an unconditional send of the same message, so each exec exception was logged twice. The message is built in the switch and sent once at the end now. pspautotests 314/314, UnitTest 55/55. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GZq8ZtJmFY7bkX5FVkr3P9
34 lines
1.2 KiB
C++
34 lines
1.2 KiB
C++
#pragma once
|
|
|
|
#include <cstdint>
|
|
|
|
#include "Core/MIPS/MIPSStackWalk.h"
|
|
|
|
namespace Memory {
|
|
|
|
void MemFault_Init();
|
|
|
|
// Used by the hacky "Resume" button.
|
|
//
|
|
// TODO: Add a way to actually resume to the next instruction,
|
|
// rather than just jumping into the dispatcher again and hoping for the best. That will be
|
|
// a little tricky though, with per-backend work.
|
|
bool MemFault_MayBeResumable();
|
|
void MemFault_IgnoreLastCrash();
|
|
|
|
// Called by exception handlers. We simply filter out accesses to PSP RAM and otherwise
|
|
// just leave it as-is.
|
|
bool HandleFault(uintptr_t hostAddress, void *context);
|
|
|
|
}
|
|
|
|
// Stack walk utility function, walks from the current state. Useful in the debugger and crash report screens etc.
|
|
// Doesn't exactly belong here maybe, but can think of worse locations.
|
|
// threadID can be -1 for current.
|
|
// startPC of 0 means "wherever the CPU is now". Pass one explicitly when the current pc is the
|
|
// problem - a jump to a bad address leaves it pointing at nothing walkable, and starting from ra
|
|
// instead still recovers the callers.
|
|
std::vector<MIPSStackWalk::StackFrame> WalkCurrentStack(int threadID, uint32_t startPC = 0);
|
|
|
|
std::string FormatStackTrace(const std::vector<MIPSStackWalk::StackFrame> &frames);
|