forums.ps2dev.org

[M.Jackson]

Hi everybody. Is there a way to manipulate the execution flow of a thread externally? I mean, if I've got a thread A which is currently running at address 0x11111111. But then I wanna suspend it, and when it resumes, I want it to start running the code from address 0x22222222 (note that the code at 0x11111111 has no correlation with the code at 0x22222222 at all, thus it is not like the code at 0x11111111 will jump to the new location voluntarily in thread A). Can this kind of manipulation be done by a separate thread B or an interrupt handler (which is not a native interrupt handler to the CPU but more like an installable handler function normally used by interrupt manager)?

To my understanding the difficulty of this is that it lacks a way to return from the code that performs scheduling (thread B or interrupt handler) to the destination that the scheduler desires. In a normal system, we usually have the exception-return instruction to take care of this (like ERET in MIPS architecture), which sort of connects the interrupt context with the non-interrupt context. But if the non-interrupt context is just a single thread inside an operating system and the scheduler is merely a routine that can not directly end the interrupt processing and jump to the new location ('cos it's just an installable function that still needs to return to the true system interrupt handler for further process), how can this job of ERET be done, or at least be simulated? If it was a linux system, I think I could probably just modify the TCB structure of thread A to achieve this. But how can this be done in PSP firmware?

[TyRaNiD]

Well overly wordy, why didn't you just ask for how to get the thread context ;)

It can be done in kernel mode but you have to be very careful about it because you need to fix the _actual_ EPC and not necessarily the one in the context :P

Look at thctx.c in psplinkusb, it uses ThreadManForKernel_2D69D086 to get the context from a UID (ensure you define your FW version when compiling as the context structure is different above around 3.X). Then you need to either fix the EPC if there is no syscall context or fix the syscall context EPC otherwise.

[J.F.]

User mode cannot get a thread context? I guess that means you'd need to make an external kernel-mode prx where the user app calls it with the thread uid and it passes back a pointer to the context, then another call to set the context after it's been modified (if that is what is needed after modifying the context structure).

[TyRaNiD]

Nope it is kernel mode only. You would obviously have to ensure the thread is suspended before playing with the context otherwise who knows what would happen ;)

[J.F.]

[M.Jackson]

thanks, guys. thanks for all the details :)

[M.Jackson]

I know this may sound stupid, but where can I get the source of psplink? Everywhere I found via google only provided the prebuilt version for download.

Thanks!

[TyRaNiD]

Urm subversion perhaps ;)

svn://svn.pspdev.org/psp/trunk/psplinkusb

[M.Jackson]

[M.Jackson]

ok, forget about the trouble I had with subversion. when reading thctx.c, I found that there seemed to be a little bit of overlay inside the structure of SceKernelThreadKInfo. For example, the filed of EPC exists in both thContext (of type SceThreadContext) and scContext (of type SceSCContext). And there is also a field of retAddr with its name reasonable enough to make me believe it is also for preserving the location where the thread should be resumed from. So which field actually tells the "true" return address if the thread is interrupted by a syscall for instance?

In addition, thContext saves all 31 GPRs which naturally includes sp, ra and k1 ($29, $31 and $27), but scContext also has members of sp, ra and k1. So which one actually tells the valid values when a h/w interrupt or syscall occurs? What are the differences between thContext and scContext in general?

PS: I did notice how the code in thctx.c selects one value over another between thContext and scContext. But I would like understand the reason behind it, the grounds backing those selections, instead of just blindly mimicking the code in future :)

[jimparis]