help needed with someone with following skills:debugger breakpoints psplink exception

[agent_dark64]

I'm trying to catch a 'break' instruction exception (0x0000000D machine code). I have successfully installed the exceptionhandler using:

result = sceKernelRegisterPriority ExceptionHandler(9, 1, exceptionhandler);

i'm using 9 because that catches break instructions apparently. The result will equal 0 indicating success.

now all my exceptionhandler has is a while(1) {} to create an infinite loop inside, nothing fancy.

i replace a instruction with the break instruction, when the psp executes that instruction it flicks off indicating a crash. I'm doing this in the 3.02 firmware, i heard that maybe on 1.5 will only let you catch exception but i may have misheard.

What is really pissing me off is i change the first instruction at 880206C0 (Default exception handler inside exceptionman.prx in 3.02 firmware), to a j 0x880206C0 (to keep looping at same spot) but it still friggen crashes somehow?? and it crashes AFTER i have written to 880206C0 - i have kernel write access.

I think i need tyranids (psplink author) help. Anyone know?

[Fanjita]

Did you flush the data and instruction caches? Could be that you're just executing cached code, rather than your modified code.

[agent_dark64]

Originally Posted by Fanjita

Did you flush the data and instruction caches? Could be that you're just executing cached code, rather than your modified code.

Yeah i tried that, no good. What baffles me is that the default exception handler points to an address where the instructions at that address are
beq zero, zero, (Jump to same address) resulting in infinite loop. Now to my understanding a syscall generates an excpetion which eventually invokes the syscall handler.

1. I'm trying to understand the default exception handler (the difference between this and the priority exception handler). Is this the memory address that the hardware will set the instruction pointer to when ANY exception occurs.

2.With the syscall sceKernelRegisterPriority ExceptionHandler does this register a exception handler based on the result of the CAUSE cop0 register that is invoked from the default exception handler?

3. If the default exception handler is the handler that the hardware calls when ever a exception is raised, how come it is by default set to a instruction that does beq zero,zero, (jump to same address) when a syscall will generate an exception (and that theorectly will jump to the beq zero, zero, (jump to same address) infinite loop code? How can a syscall succeed then?

This has got me thinking, maybe theres a cop0 register i'm suppose to set a bit on which enables exception handling, maybe the exception handler is turned off by default, at least maybe 3.02 turns it off by default?

[agent_dark64]

ahh, k, starting to understand things. a Syscall raises an interrupt, not an exception, but by definition of an online documentation a syscall should therorectly raise an exception. So it seams that the exception handler may not be enabled/active, or may not be able to be enabled/activated on 3.02 firmware.

[agent_dark64]

I'v just figured out finally what the problem is and got around it, and i'v seen alot of people wondering how to build a debugger so here it is on 3.02:

After 2 months, the answer has come with no help from community so i will share it here for anyone like tyranid.


Firstly, the sceKernelRegisterPriority ExceptionHandler syscall REQUIRES the first 4 bytes of the exceptionhandler you are registering to be nop - all 4 zero bytes (0 in machine code), it will return 0x80020034 otherwise which is defined incorrrectly in the SDK as exception_in_use - this is absolutely incorrect.

Second, at least the 3.02 firmware and above CHECKS the cause cop0 register in the psp exception handler (it is defined in exceptionman.prx) and prevents certain types of exceptions to be handled (prevents Jumping to the function you defined with sceKernelRegisterPriority ExceptionHandler). If you come accross a excpetion the operating system decides not to handle, the psp purposely crashes (which then flicks your psp off).

This site is the best resource to learning the psp exception handler:
http://hitmen.c02.at/files/yapspd/psp_doc/chap9.html

exception_handler(u32 offset /* v0 */) /* 8801cd70 (exceptionman:0x0670) */
{
if (COP0CTRL.25!=NULL) /* Profiler HW Base */
{
; profiler stuff
*(PROFILER+0x0c)=offset; /* save v0 to PROFILER+0x0c (stall total) */
v1=*(PROFILER+0x00);
v0=*(v1+0);
*(v1+0)=0;
sync();
if(*(PROFILER+0x08)==0)
{ *(PROFILER+0x04)=v0;
} ; count cpu ticks
*(PROFILER+0x08)++; /* cpu ck */
offset=*(PROFILER+0x0c); /* get v0 from PROFILER+0x0c (stall total) */
}
/* jump to exception handler from table */
u8 *Exception_Vector_Table;
Exception_Vector_Table=CO P0CTRL.8; /* Exception Vector Table */
call((u32)Exception_Vecto r_Table[offset]);
}

on the standard 3.02 (no custom firmware) while in VSH this is loaded at:
880206C0

you will see a few nops (0x00000000 machine code) above this address.

you first need to patch 880206E8 which is the branch:
bne v1, v0, 0x880206F8
you must force this branch, the code 2 lines below causes your psp to always crash (because v1 does not contain a valid address):

jr $v1

next you need to force the branch at 880206FC which is:
beq $zero, $v1, 0x8802073C

now if you put a break instruction (0x0000000D machine code) and register an exception handler with excpetion number 9, it will jump into your exception handler!!


Hope this helps someone. Let me know if it works.

[MacTheFork]

The community probably didn't respond cause a) most people are idiots ;P and b) the code to do what you wanted it hiding in plain sight. You still don't seem to have much of a clue even now.

For a start if you want to catch break exceptions you can either use the default handler (sceKernelRegisterDefault ExceptionHandler) or insert a priority exception handler on 9 with the lowest priority. There is no need to hack the kernel what so ever, psplink runs quite happily on 3.X (admittedly custom firmware versions but they dont touch that stuff afaik in those) with full debugger support.

The reason you need the first 4 bytes as a nop is because it writes the chain address to that location when you register your exception handler, that is why the error code indicates exception in use because if it isn't 0 it thinks you have already registered it.

Of course just getting code in there to handle the exception isn't enough, you actually have to do something with it otherwise the psp will power off anyway. The trick is to not only handle the exception but also to resume afterwards.

Have fun

[agent_dark64]

Originally Posted by MacTheFork

The community probably didn't respond cause a) most people are idiots ;P and b) the code to do what you wanted it hiding in plain sight. You still don't seem to have much of a clue even now.

For a start if you want to catch break exceptions you can either use the default handler (sceKernelRegisterDefault ExceptionHandler) or insert a priority exception handler on 9 with the lowest priority. There is no need to hack the kernel what so ever, psplink runs quite happily on 3.X (admittedly custom firmware versions but they dont touch that stuff afaik in those) with full debugger support.

The reason you need the first 4 bytes as a nop is because it writes the chain address to that location when you register your exception handler, that is why the error code indicates exception in use because if it isn't 0 it thinks you have already registered it.

Of course just getting code in there to handle the exception isn't enough, you actually have to do something with it otherwise the psp will power off anyway. The trick is to not only handle the exception but also to resume afterwards.

Have fun

Thanks, i'v figured all this stuff and got it to resume using the eret instruction, If i set a breakpoint in kernel memory, it will successfully jump into my exceptionhandler and resume with any problems, however if i set the break instruction in user mode memory, it doesn't even jump into my exception and the psp just powers down maybe theres a cpu bit i'm suppose to enable to allow it to work in user mode :/ or maybe it throws a different exception number for user mode. Maybe break isn't considered a valid instruction from within user mode or doesn't have user mode privledges.

[MacTheFork]

Your problem with user mode is one of processor states, when you exception in a user mode thread if you then eret back to a handler which is in kernel memory it will exception again because the user mode thread cannot access the kernel memory, depending on how you've written your exception handler it will continue to do this ad infinitum and the watchdog will eventually kill you.

You can fix this one of two ways, do it like psplink does (or used to do?) and have a trampoline in user memory and bounce all exceptions through that, _or_ transition into kernel mode and call your kernel handler, something which is slightly more difficult to acheive Ill leave the details up to you.