Misc issues with PPSSPP debugger integration

[kotcrab]

trafficstars

• Target is already being recorded when transitioning between stepping and running states. Needs investigating, could be an issue in Ghidra.
  • See https://github.com/NationalSecurityAgency/ghidra/discussions/3559
• Current frame's bank does not exist when clicking through stack frames, PPSSPP doesn't expose such information. Some workaround needed, maybe we just need to provide an empty register bank
• Step out error is ignored - e.g. when there is no more stack frames. Ghidra steps are async so not much can be done about this, it just might be confusing to the user
• Can't trigger breakpoint hit events - will be available thanks to https://github.com/hrydgard/ppsspp/pull/15051

[unknownbrackets]

when clicking through stack frames, PPSSPP doesn't expose such information

What's it looking for? We do try to work backwards on what RA was, which is how it does the stack walk at all. It's not as sophisticated as gathering all the registers, though. What would this enable within Ghidra?

-[Unknown]

[kotcrab]

The debugger can provide model of the CPU registers values for each stack frame. I think this just allows to view and change registers on each stack level. I don't really understand how debugger could know this but maybe this is intended for different types of processors. The goal here is to just stop that error message from showing.

[unknownbrackets]

Well, in theory this is doable, although a pain to work out.

For example, consider a chain of function calls:

• Func1 uses all a, s, and t regs, and calls Func2.
• Func2 doesn't use any s regs, but takes several arguments and calls Func3.
• Func3 uses all s regs.

In this case, Func3 will have had to save s0, s1, etc. to the stack before using them. So in theory, if you wanted to know the value of s0 in the Func2 or Func1 stack frame, I could tell you - it's the value on Func3's saved stack. I could work out, using the prologs and epilogs alone, what the register values generally would be at any stack frame.

Of course, a0 or v0 etc. might be modified in Func2 before it returns to Func1, so I couldn't work that out. Anything not saved, I'd just have to assume the current value (outside maybe some tricks if something is obviously saved in an s reg, etc.)

PPSSPP is really only doing this for RA and SP, look for // Here's where they store the ra address. in the code.

-[Unknown]

[kotcrab]

So it's possible to figure out to some extent, interesting but probably not something worth spending time on. The uses for that are rather limited. I think it's good enough we can get stack frames at all.

[sajattack]

Any plans for psplink/gdbserver integration?

[Nemoumbra]

So... As of August 2, 2023...

1. It's probably still a Ghidra issue (I couldn't find if this was fixed in the Ghidra repo), but apparently there's a workaround: we need to uncheck "Record Automatically" and hit "Record" after we've launched to prevent the error from popping up.
2. Saving all the register values in all stack frames by PPSSPP is very expensive and we can't effectively figure the values out all the time via stack walking due to our register-based calling convention. Does the plugin provide the empty bank right now?
3. Why doesn't the async code produce any error messages?
4. Has this been implemented? I suggest kotcrab to edit the message ~accordingly~ if that's completed.

[kotcrab]

There wasn't really any changes to the integration since this issue was created so those points still stand.

Why doesn't the async code produce any error messages?

I think the issue was with there being no way to deliver the unsuccessful step out event to the Ghidra but not sure.