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?
A question about thread manipulation in homebrew programming
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.
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.
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).
That's EASY to figure out... BOOOOOOOOOMMMMMM!!!!!!! ;) :)TyRaNiD wrote: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 ;)
Yes, on the Amiga you'd do a Forbid()/Permit() around the code in question. Some people preferred to do Disable()/Enable()... just to be extra safe. I've seen int disable/enable used in code on the PSP. Personally, I've yet to do anything on the PSP that requires more than remembering the PSP uses cooperative multitasking.
I guess the url above only works on the svn type of access. But since my pc is behind a firewall which i don't have any authority to config (otherwise I think I could have changed the NAT table allowing me to pass through), the only way out for reaching the internet is through a http proxy server. So I modified the config of subversion specifying the proxy, and attempted to access this url http://svn.pspdev.org/psp/trunk/psplinkusb instead, but got the following response:TyRaNiD wrote:Urm subversion perhaps ;)
svn://svn.pspdev.org/psp/trunk/psplinkusb
$ svn co http://svn.pspdev.org/psp/trunk/psplinkusb .
(I tried "svn export http://svn.pspdev.org/psp/trunk/psplinkusb ." too, but got the same result)
svn: PROPFIND request failed on '/psp/trunk/psplinkusb'
svn: PROPFIND of '/psp/trunk/psplinkusb': 405 Method Not Allowed (http://svn.pspdev.org)
Does this mean the subversion server was not configured to serve http requests? If that's the case, I will try to find a way to get the source outside the firewall.
Or, could it just be me using a wrong way to access the repository? because I can view all the files in /psp/trunk/psplinkusb through a web brower normally, which probably suggests the server are willing to offer its content through http protocol as well.
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 :)
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 :)
HTTP mirror hereM.Jackson wrote:I guess the url above only works on the svn type of access. But since my pc is behind a firewallTyRaNiD wrote:Urm subversion perhaps ;)
svn://svn.pspdev.org/psp/trunk/psplinkusb
http://forums.ps2dev.org/viewtopic.php?p=34778#34778