Project

General

Profile

Emulator Issues #13044

Debugger: CheckBreakPoints is hit twice per breakpoint.

Added by taolas 6 days ago. Updated 3 days ago.

Status:
Accepted
Priority:
Normal
Assignee:
% Done:

0%

Operating system:
N/A
Issue type:
Bug
Milestone:
Regression:
No
Relates to usability:
No
Relates to performance:
No
Easy:
No
Relates to maintainability:
No
Regression start:
Fixed in:

Description

What's the problem? Describe what went wrong.

PowerPC::CheckBreakPoints in Jit.cpp and JitAsm.cpp are both hit on a breakpoint. This produces two log outputs per one hit. Also, working on future stuff and having it hit twice is not good. This is for code breakpoints.

Is the issue present in the latest development version? For future reference, please also write down the version number of the latest development version.

Yes, it seems to have been around for quite awhile.

Other Info
I removed the one from JitAsm and it didn't cause any issues for me, but I don't really know if this is the correct fix. The call doesn't return anything, so I don't think it's needed for more than triggering a breakpoint report. So my other question is: Are both jit and jitasm debug sections always hit together? Is this platform dependent?

History

#1 Updated by JosJuice 5 days ago

  • Assignee set to JosJuice
  • Status changed from New to Accepted

I think the reason why this wasn't noticed before is that if you enable breaking on the breakpoint (which I imagine is the most common), Dolphin will break after the JitAsm.cpp check and thus not run the Jit.cpp check.

The intent seems to be that the JitAsm.cpp check runs between blocks and the Jit.cpp check runs in the middle of blocks, but if you place a breakpoint at the beginning of a block, you end up triggering both.

#2 Updated by JosJuice 5 days ago

Can you check if breakpoints behave as expected in this pull request? https://github.com/dolphin-emu/dolphin/pull/11077

#3 Updated by taolas 5 days ago

Thanks for looking at this so quickly. The changes actually break a lot of debugging stuff. Step Over goes wacky. Breakpoints stop the game on wrong addresses, etc. I think the jitasm debugging stuff is necessary for things to function properly.

I went back and looked at my test-removal of this from jitasm:
ABI_PushRegistersAndAdjustStack({}, 0);
ABI_CallFunction(PowerPC::CheckBreakPoints);
ABI_PopRegistersAndAdjustStack({}, 0);

It appeared to work, but now I see it no longer puts our a log message when it breaks on a breakpoints, as jitasm prevents the jit hit on break like you said.

So we have generally working behavior when breaking/pausing on a breakpoint and broken duplication when logging, but not pausing for, the breakpoint. The duplicates on log-only may seem like a minor issue, but are causing bigger issues on future work.

#4 Updated by JosJuice 5 days ago

Okay, thanks for testing. Seems like I'll have to do more in-depth testing of this.

#5 Updated by taolas 4 days ago

I made a mistake. I thought setting a code breakpoint in the code tab would flag it for being logged, but it doesn't. I re-ran my previous test with

ABI_PushRegistersAndAdjustStack({}, 0);
ABI_CallFunction(PowerPC::CheckBreakPoints);
ABI_PopRegistersAndAdjustStack({}, 0);

removed from jitasm and manually setting break and log. Everything looks to be working correctly. This could be a potential fix.

#6 Updated by JosJuice 4 days ago

But how about the pull request? Is that one still buggy?

#7 Updated by taolas 3 days ago

Yeah. The PR makes Breakpoints and stepovers take you to random places. Completely broken.

Also available in: Atom PDF