Hi, Whenever i try to start executing first thread in a new address space, its pager is receiving pagefault (at 0x0000002b), eventhough none of the mapped code touches that place. Why is it? I found out that CHACMOS is mapping trampoline.S at that address. I What is this trampoline.S is for? I tried to understand trampoline.S code, but i couldn't. I didnt find any FAQ entry regarding this. Can anyone please help me here? NOTE: I am using pistachio-0.4 Thanks, -bvk
[BVK Groups]
Hi, Whenever i try to start executing first thread in a new address space, its pager is receiving pagefault (at 0x0000002b), eventhough none of the mapped code touches that place. Why is it?
I found out that CHACMOS is mapping trampoline.S at that address. I What is this trampoline.S is for? I tried to understand trampoline.S code, but i couldn't. I didnt find any FAQ entry regarding this. Can anyone please help me here?
NOTE: I am using pistachio-0.4
Don't know the chacmos code and can't tell what it does. I can tell you what trampoline.S in Pistachio is used for, though. In some cases that kernel creates some form of "asynchronous event" for another thread. This is implemented by creating a new stack frame on the kernel stack of that thread. The next time this thread is activated, the context described by this new stack frame is started. The new context is actually a function invokation (see the invoke() methods in include/glue/v4-ia32/tcb.h). If we have to pass some parameters to this function, the parameters have to be popped off the stack before the old context is resumed. This is what the notify_trampoline in trampoline.S does. It simply pops two parameters off the stack and resumes the old context by jumping ("returning") to its instruction pointer. eSk
On 3/9/06, Espen Skoglund <esk@ira.uka.de> wrote:
In some cases that kernel creates some form of "asynchronous event" for another thread. This is implemented by creating a new stack frame on the kernel stack of that thread. The next time this thread is activated, the context described by this new stack frame is started. So this is purely inside kernel, using kernel stack, and i hope it will not affect user-level threads in any way, i mean, user-level threads need not know about this at all.
My problem was, i am getting pagefaults in zero-th page, even before a thread starts executing its first instruction. Is such a case possible in pistachio? When i was looking at chacmos source, its pager's are mapping trampoline.S to *every* thread, at zero-th page location. So i thought trampoline.S has something to do with these *pagefaults-in-zero-th-page*. So, my question is, 'is it possible to get pagefaults from a new thread, even before executing it start execution?' thanks, -bvk.
I got it now. On 3/9/06, BVK <bvk.groups@gmail.com> wrote:
So, my question is, 'is it possible to get pagefaults from a new thread, even before executing it start execution?'
It seems, if we didn't ZEROed the UTCB area before creating a new thread, we can get such pagefaults. I dont know why :-(
On 03/08/06 19:43, BVK Groups wrote:
I found out that CHACMOS is mapping trampoline.S at that address. I What is this trampoline.S is for? I tried to understand trampoline.S code, but i couldn't. I didnt find any FAQ entry regarding this. Can anyone please help me here?
My interpretation of trampoline.S in CHACMOS follows: In CHACMOS, the code in trampoline.S is mapped into newly created address spaces at address 0. CHACMOS starts the initial thread in those address spaces at address 0. The code in trampoline.S implements a tiny server that waits for IPC messages from the root task. The functions that can be invoked are (function number in dw0, parameters in dw1+dw2): 0) receive a string message 1) zero-fill a region 2) change the pager of the initial thread in the address space 3) jump to an address This allows populating the address space and configuring the initial thread before launching the actual application code for that address space. Uwe
participants (4)
-
BVK -
BVK Groups
-
Espen Skoglund -
Uwe Dannowski