Status of the PCSX2 debugger
#1
This question may be better asked in the Developer's Forum but I only have very quick questions on it.

I'm currently poking around in a game to find out how it works and I remembered at one point, PCSX2 had a debugger in it to use for doing this sort of thing.

Doing a bit of research, I found out that it has been deprecated since 0.9.6(?) and normally, people would not have a use for it so it was not available in release builds. So with that mindset, I went and compiled PCSX2 with VS2010 to see if I could get it in either the debug or developer builds. I did not think that it was removed completely but the option was not in the menu for either build and looking around in the code, it seemed to have disappeared completely. I poked around your branches and managed to find your legacy GUI code but it seems that it was left in a quite sorry state to say the least (which is probably why you guys removed it completely) so with that in mind, I just want to ask:

1.) Why was the debugger removed completely from your codebase? Was the bugginess of the code a problem going from around 0.9.6 or was it supposed to be completely rewritten at some point and removed for that purpose?

2.) Is there currently work being done on it? Is there a specified time or release that you're planning to reintegrate it?

3.) Is there still a SVN revision branch of code or build or such where I can find this feature still working somewhere?

4.) There is only logging available for the builds of PCSX2 that are currently maintained and that it provides trace logging. How does that differ from live code tracing?

Thank you for your time in reading and responding to this.
Reply

Sponsored links

#2
1) Much of the code is still there. What's really missing is the gui that would have to be written in WX.

2) Nope, it's a lot of work to get everything going again, especially since the debugger was always pretty bad (and no one likes gui coding, too).

3) You could try something in the revision 1000 range on googlecode.

4) All the logging is done to emulog.txt. So you'll easily end up with a multi gigabyte text file. Have a good editor at hand! Tongue2
Reply
#3
It really has to be said that the pcsx2 debugger as it was would likely not have been very helpful in reversing your game. It was pretty much only usable for code breakpointing and stepping.
Reply
#4
ahuh. questions here: so you devs don't even have an internal debugger to fix some games special techniques? how you do that then? you know how it all works or you guess and gamble?

i mean ps2 c code is pretty forward to think thru, where assembly is not to look cool to debug. but you don't have game's codes. mmmhh?
Reply
#5
(03-24-2012, 11:17 AM)rama Wrote: 1) Much of the code is still there. What's really missing is the gui that would have to be written in WX.

2) Nope, it's a lot of work to get everything going again, especially since the debugger was always pretty bad (and no one likes gui coding, too).

3) You could try something in the revision 1000 range on googlecode.

4) All the logging is done to emulog.txt. So you'll easily end up with a multi gigabyte text file. Have a good editor at hand! Tongue2

1.) So everything is there? Which subfolder in the solution is the code in?

2.) Well, that's to be kinda expected. But work isn't being done in terms of fixing the base debugger code without the GUI? At the very least, it should still be able to post something in the console or something... It could also help you immensely in terms of finding where exactly the emulator goes wonkers at times too. I'm surprised that this doesn't have more priority... Edit: Also, what is RW?

3.) I've heard somewhere that around 0.9.2, that was the last version where the debugger "worked". Do you have the revision numbers for each release somewhere from 0.9.2? Thanks.

4.) I tried using it but most of this is logging which internal competent does what with data as if it was an actual PS2? It kinda helps but specifically, I need help finding some drawing routine the game I'm interested is using. Which options should I log so that I don't end up searching ~50,000+ lines (That's what I got with everything on with the emulator running for less than 30 s)?

(03-24-2012, 12:20 PM)pseudonym Wrote: It really has to be said that the pcsx2 debugger as it was would likely not have been very helpful in reversing your game. It was pretty much only usable for code breakpointing and stepping.

It would be a great help if it was working, which at one point, it probably was. I need to find where a text routine is located specifically in a binary file, as to which case, I've disassembled the whole file and came out with around 450,000 lines of MIPS assembly, and have narrowed it down to around half that much. With the debugger, knowing what's actively in memory at the time of code execution would make understanding what the game does better and would be pretty fast in telling me where exactly this text routine is instead of a complete nightmare and a special exercise in intellectual masochism, which I've already labored somewhat a lot over into eliminating which locations it's not in in the span of a month and a half. I'm also stuck at a crossroad right now in terms of having around 9 locations where this text routine probably happens but these 9 locations contain 95% of the remaining code I haven't eliminated. So yeah, I could really use some sort of help with figuring that out. Unsure
Reply
#6
I mostly work with static disassembly, existing logs and sometimes traces or memory dumps I add to the emulator's code. If you're trying to find text rendering I'd suggest you either try to find a place where it's definitely used with a known string or find script decoding in the disasm or find where the typeface is loaded and find other references to that memory.
Reply
#7
(03-25-2012, 03:52 AM)pseudonym Wrote: I mostly work with static disassembly, existing logs and sometimes traces or memory dumps I add to the emulator's code. If you're trying to find text rendering I'd suggest you either try to find a place where it's definitely used with a known string or find script decoding in the disasm or find where the typeface is loaded and find other references to that memory.

Thank you for the tips. However, with only logging, I can't really do much in trying to find it. You said that you use memory dumps also. Where, may I inquire, can I get that feature because the debug menu only shows Logging.

But other than that, do you know what specifically I should use for Trace Logging so I don't end up with a bunch of other logged lines that aren't relevant to my search?

I do not want to downplay the fact that your method is entirely possible to use to find bugs and such in the code for PCSX2 and specific games. However, that shouldn't downplay a debugger, which is a significant feature that could help you guys make emulation bugs easier to find and figure out the nuances in specific games. It does surprise me that no one has tried to write a basic GUI to use the code which already exist for this purpose and that it doesn't have a higher priority for the developers.

I might end up writing one myself or end up fixing an older release if I end up on a dead end with your methods. My knowledge of doing such static code analysis is beyond my skill level in my opinion, but I'm willing to give it a shot.
Reply
#8
Being the one who got the debugger working again late in the old GUI versions, I think I do know how useful it was. The answer is "not very". It didn't even have a call stack, you know (let alone things like thread information).

Regarding the memory dumps I hardcoded them, it's just a few lines of code, and when I said traces I also mean ones I added to the code. What built in logging options to use entirely depends on what you're looking for. Unless it's very closely connected to a hardware function you're unlikely to get anything useful, and of course you have to know the PS2 well to know whether it might be.
Reply
#9
(03-26-2012, 03:50 PM)pseudonym Wrote: Being the one who got the debugger working again late in the old GUI versions, I think I do know how useful it was. The answer is "not very". It didn't even have a call stack, you know (let alone things like thread information).

Regarding the memory dumps I hardcoded them, it's just a few lines of code, and when I said traces I also mean ones I added to the code. What built in logging options to use entirely depends on what you're looking for. Unless it's very closely connected to a hardware function you're unlikely to get anything useful, and of course you have to know the PS2 well to know whether it might be.

Well, since we're getting into specifics at the moment, I might as well stop being vague about what it is I want to do. It is in a grey area though, I might say, so I do apologize if that breaks any forum rules as it doesn't really say if I'm allowed to state this but it might fall under "warez".

I'm trying to figure out how to get a visual novel made for the PS2 to accept ASCII in order to try and translate it. Modifying the game, it was found that it would not accept any ASCII characters and essentially, changing the script file with ASCII will not print these characters when the game was modified to run with it. The theory is that because there are some control sequences that are use ASCII characters, the game basically ignores them when they are put in the script. The temporary solution now is to print letters using double-width characters but that essentially gives very little room to translate the text. The long term solution is to find out either how to get it to recognize the characters and get the game to print them or to develop a variable width font for the game, which is what I'm trying to do and is why I'm trying to find the text routine so I can actually modify it.

I don't know if it's due to the incompetency of my skill with code and analysis or the unfamiliarity of my knowledge of the PS2. But I do believe that actually breaking at the some moments during the game and looking at what the processor is doing will help me somewhat with this process. Unless there's a better way to do it with debugging the emulator itself in Visual Studio specifically by putting in code and such, I do believe this debugger will help me a bit more than the logging that's already built in the emulator at the moment with the SVN builds despite not having threading information and a call stack.

I do also recognize, as indicated above, that I am woefully inexperienced most likely with the PS2 hardware and its internal workings. Is there any resources I may be able to get in order to get more acquainted and familiar with whatever it is doing?
Reply
#10
We do want to get a debugger into pcsx2 again but we're aiming for something more useful than the old one and it hasn't been a priority. It sounds like you're expecting to get something out of manually breaking and... you won't. You won't even land in game code, you'll find yourself staring at part of the kernel. This is especially true of a "game" with as little processing as a visual novel.

I can give you some more specific advice or help, but that's not rather technical for this forum and not directly related to pcsx2, so check your PMs.
Reply




Users browsing this thread: 1 Guest(s)