Tim Robinson wrote:
I avoided this issue by giving new processes a page directory with the bottom half full of zeroes and the top half full of the kernel address space (as normal). The first thread starts at a well-known address (0xdeadbeef).
The new thread will fault straight away and trap into the kernel, which can then allocate some memory in the address space of the new process, load some code and reassign the EIP of the thread to the entry point of the program.
Hehe ... interresting trick. I noticed there are some 0xdeadbeef in Linux Kernel aswell, but i can't remember why and where ... do you think they use the same trick as you do or is it an original idea from you ?
Btw, in Clicker, there is a special thread (the ProcessManager) that has the ability of moving from one address space to another, so when you create a new process, you first build a address space which is a complete copy of the current one and then ask the process manager to go tidy up that place. It will then remove pages that shouldn't be kept and make other pages copy-on-write if needed, etc. Once this is completed, it can also spawn new threads that will live in that address space before it returns to the Kernel Initial address space.
Maybe i should give a deeper look at your technique, as it seems way easier to deal with (though i'm not sure it is portable to Clicker :-/)