[Feature Request] debugger: Memory breakpoints

[elad335]

Alongside #9002, lack of breakpoint types supported by the debugger.

[dio-gh]

This feature would be immensely useful, seconded. Especially if it would support different kinds of bp's like CE, thinking of read/write/access here.

Bumping the thread to signal the need.

[I-Knight-I]

Registering my interest in this and bumping.

Using CE is a bit of a pain, so it'd be nice to have that functionality natively built-in.

[Nekotekina]

I want to try to implement "software" memory breakpoints, instead of relying on x86 limited hardware. Before screaming "NOOO IT WILL BE TOO SLOW" I want to actually analyse its impact on overall performance. Cross-platform "sparse memory" (usually called overcommit memory) support (rpcs3_vm) was made for this purpose.

[eadmaster]

what about using CCAPI?

[elad335]

#9621 (comment)

Unless we port RPCS3 to a real PS3, I do not see any use in this.

[VelocityRa]

Not sure what sparse memory has to do with implementing this feature, could you explain? Sounds interesting.

Fwiw I think the x86 hardware limitation of 4 breakpoints at a time per thread is fine for the vast majority of use cases.
With guaranteed no overhead & relatively simple to implement.

But I suppose the decision is up to whoever wants to actually do it.

[VelocityRa]

Btw just in case anything can be salvaged (doubtful), there is old/slow support for this for Interpreter here: VelocityRa@f787601

[Nekotekina]

When hw breakpoint is hit, the overhead of exception handling is pretty high. Only in simple use cases it doesn't matter. Software breakpoints can avoid this overhead in theory, thus enabling fast conditional breakpoints and similar advanced features which could otherwise be either slow or not working due to disproportional overhead.

Sparse memory exploits the typical implementation detail of memory overcommitment: memory pages appear as zeros until written, but these zeros aren't occupying physical memory yet, mirroring a single zero page instead. It occupies much less RAM when unused. It should avoid cache miss on random access in most cases, or at least reduce it to TLB miss.

Few instructions fetch either zero or a handler address from "sparse memory" for given PS3 VM address being accessed. It's possible to implement in various ways (test + cc jmp, or unconditional call of the dummy handler), I don't know exactly what approach is optimal here, need to test it.

Finally, it seems possible to implement classic execution breakpoints using the same approach, and make them work with PPU LLVM without tricky patching.

[BlackStar-EoP]

Btw just in case anything can be salvaged (doubtful), there is old/slow support for this for Interpreter here: VelocityRa@f787601

Integrated this into the latest code, it did require some changes, but I got it to compile.

Unfortunately, RPCS3 crashes immediately when starting up a game and trying to figure out what's going on with zero knowledge of this project isn't going to be easy.

Edit: managed to get things running, possibly incremental linking that messed something up.
I've committed the change to my fork in [0b4cb5c] haven't tested it yet though.

Quality wise, I wouldn't merge this back, the g_breakpoint_handler is a klutz and checking the map on every load/store instruction isn't very efficient.

[eadmaster]

I've committed the change to my fork in [https://github.com/RPCS3/rpcs3/commit/0b4cb5c3dc464aa491b45ee6e53ce478d08766a4] haven't tested it yet though.

@BlackStar-EoP: can you share a build of your fork? I'd like to try it and see if i can use it to make some cheats.

[BlackStar-EoP]

I've committed the change to my fork in [https://github.com/RPCS3/rpcs3/commit/0b4cb5c3dc464aa491b45ee6e53ce478d08766a4] haven't tested it yet though.

@BlackStar-EoP: can you share a build of your fork? I'd like to try it and see if i can use it to make some cheats.

https://we.tl/t-1mngncrp4a

Here it is, be sure to set the CPU to interpreter

[eadmaster]

I've committed the change to my fork in [https://github.com/RPCS3/rpcs3/commit/0b4cb5c3dc464aa491b45ee6e53ce478d08766a4] haven't tested it yet though.

@BlackStar-EoP: can you share a build of your fork? I'd like to try it and see if i can use it to make some cheats.

we.tl/t-1mngncrp4a

Here it is, be sure to set the CPU to interpreter

i think i also need the correct dll files, all games fails to boot with compilation errors...

[BlackStar-EoP]

I've committed the change to my fork in [https://github.com/RPCS3/rpcs3/commit/0b4cb5c3dc464aa491b45ee6e53ce478d08766a4] haven't tested it yet though.

@BlackStar-EoP: can you share a build of your fork? I'd like to try it and see if i can use it to make some cheats.

we.tl/t-1mngncrp4a
Here it is, be sure to set the CPU to interpreter

i think i also need the correct dll files, all games fails to boot with compilation errors...

Hey eadmaster, so sorry, I completely forgot to respond to your message.

For the DLLs, this should be good, usually what I do is just replace the rpcs3 executable with my own and the whole thing starts.
For the compilation errors, I have managed to get it to work with Vulkan, but my savestates didn't load anymore with compilation errors in the shaders as well. What I did was set the renderer to OpenGL and just press ignore on all the errors that pop up.

I also hacked in a memory dump in the memory viewer that can dump a range of memory into a file :)