This forum uses cookies
This forum makes use of cookies to store your login information if you are registered, and your last visit if you are not. Cookies are small text documents stored on your computer; the cookies set by this forum can only be used on this website and pose no security risk. Cookies on this forum also track the specific topics you have read and when you last read them. Please confirm whether you accept or reject these cookies being set.

A cookie will be stored in your browser regardless of choice to prevent you being asked this question again. You will be able to change your cookie settings at any time using the link in the footer.

Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
More Debug features?
#1
As someone who is looking to use this emulator for hacking (for a game translation), I was wondering what the plans for debug features were?

I know that, looking at changelogs, there was tracing at one point, as well as Read/Write breakpoints- but they seem to have been removed since they were added. And I must say, at least Read/Write breakpoints would be an immense help to me- and I'm sure to many others in the future.

Any possibility that it might be simple to at least re-implement the memory debugging? (I see the source is still there, though, afaict, it doesn't work) And maybe add a dialog for ssettings/editing memory breakpoints in the memory viewer?
Reply
#2
(04-29-2011, 08:04 AM)Zarradeth Wrote: As someone who is looking to use this emulator for hacking (for a game translation), I was wondering what the plans for debug features were?

I know that, looking at changelogs, there was tracing at one point, as well as Read/Write breakpoints- but they seem to have been removed since they were added. And I must say, at least Read/Write breakpoints would be an immense help to me- and I'm sure to many others in the future.

Any possibility that it might be simple to at least re-implement the memory debugging? (I see the source is still there, though, afaict, it doesn't work) And maybe add a dialog for ssettings/editing memory breakpoints in the memory viewer?
The DebuggerMemory is automatically used when a file named "Memory.mbrk" is present in the main directory. The format of the file is quite simple:
Code:
R 0xXXXXXXXX
W 0xXXXXXXXX
RW 0xXXXXXXXX
R 0xXXXXXXXX - 0xYYYYYYYY
W 0xXXXXXXXX - 0xYYYYYYYY
RW 0xXXXXXXXX - 0xYYYYYYYY
read|write|read8|write8|read16|write16|read32|write32
setting read ®, write (W) and read-write (RW) breakpoints on a single address or an address range.
The last line is to enable traces of the corresponding reads and writes.
Reply
#3
Thanks for the help, it's much appreciated.

I have updated my Memory.mbrk file going by what you have said to-
Code:
W 0x88941200
read|write|read8|write8|read16|write16|read32|write32

And I know that my compiled Memory.class file sets useDebuggerMemory to true (it's disabled by default in the svn), but the emulator still isn't breaking on writes to that memory location.

I could honestly live without tracing, but breaking on memory read/writes would help me astronomical amounts.
Reply
#4
(04-30-2011, 08:16 AM)Zarradeth Wrote: Thanks for the help, it's much appreciated.

I have updated my Memory.mbrk file going by what you have said to-
Code:
W 0x88941200
read|write|read8|write8|read16|write16|read32|write32

And I know that my compiled Memory.class file sets useDebuggerMemory to true (it's disabled by default in the svn), but the emulator still isn't breaking on writes to that memory location.

I could honestly live without tracing, but breaking on memory read/writes would help me astronomical amounts.

Sorry, I forgot one additional option "pause":
Code:
read|write|read8|write8|read16|write16|read32|write32|pause
When "pause" is specified, the emulator is pausing when reading/writing the selected addresses. Otherwise, the emulator is just logging at INFO level the memory access (this is the option I usually use, I find it easier to go through a log file).

You don't need the readX|writeX options if you are not interested in tracing all the memory reads & writes. E.g., for just a write breakpoint:
Code:
pause
W 0x88941200

Also, open the Debugger window before pressing the "Run" button to have full debugger functionality (the compiler is removing debugger calls when the debugger window is closed).

BTW, you don't have to modify Memory.java, when the file is present, the debugger memory is activated:
Code:
if (useDebuggerMemory || new File(DebuggerMemory.mBrkFilePath).exists()) {
    DebuggerMemory.install();
}
Reply
#5
Okay, I tried adding the pause and I still get nothing, I setup the logger to run at info level, don't get anything in the logs. I tried setting a write breakpoint on about a 20h range around the value, nothing. I tried using a value that is modified by the game much more often, still nothing.

The only time I can get the emulator to break or log anything is when I setup it up with a break on reading, and I use the memory viewer to view the address. The breakpoint will trigger when I press 'go to address' (to update the viewer), but not when the game reads/writes to the values.

I tried using exactly what you gave me:
Code:
pause
W 0x88941200
and it didn't work, it didn't pause execution or output anything to the logger. And I'm having the emulator start with the debugger open so I know it isn't that. (I did revert back to the unmodified .jar of r2100 from Orphis, didn't change anything). Undecided

Edit: I take back what I said, it's working- I've used other values (0x09FFFDF0) that I know the game modifies early on and it's triggering the breakpoint for it- I don't know why the later values (in RAM) aren't getting triggered.
Edit 2: I got it working, after looking up some memory mappings/partitions I realized that I was breaking on kernel memory, which the game shouldn't be writing to itself. The game was actually writing to 0x08941200.

Thanks for the help though, there wasn't much/any information lying around explaining the format for the Memory.mbrk files, so this was still helpful, and hopefully someone in the future might find this information helpful.
Reply
#6
(04-30-2011, 12:51 PM)Zarradeth Wrote: Edit: I take back what I said, it's working- I've used other values (0x09FFFDF0) that I know the game modifies early on and it's triggering the breakpoint for it- I don't know why the later values (in RAM) aren't getting triggered.
Edit 2: I got it working, after looking up some memory mappings/partitions I realized that I was breaking on kernel memory, which the game shouldn't be writing to itself. The game was actually writing to 0x08941200.
I've fixed this in r2109 and also in other situations were the breakpoints were not always recognized.
Thanks for the feedback!
Reply


Forum Jump:


Users browsing this thread: 3 Guest(s)