On Wednesday 14 October 2009 06:52:10 you wrote:
> On Tue Oct 13, 2009 at 13:01:46 +0800, Guanghui, Cheng wrote:
> > On Monday 12 October 2009 02:03:41 Adam Lackorzynski wrote:
> > > On Sun Oct 11, 2009 at 22:17:49 +0800, Guanghui, Cheng wrote:
> > > > From the l4-x2 manual it is said the reply from the exception
> > > > handler contains a label, an instruction pointer where the faulting
> > > > thread is resumed. I want to know whether it is implemented in the
> > > > Fiasco. I try to do this. Modify the utcb before send ipc resume the
> > > > exception thread but it seems no any effect about the instruction
> > > > pointer and stack pointer of resumed exception thread.
> > >
> > > My guess would be that you did not set the number of words to send in
> > > the reply. Set L4_UTCB_EXCEPTION_REGS_SIZE in the msgtag-words field of
> > > the reply.
> >
> > Hello Adam:
> > Now i use L4_UTCB_EXCEPTION_REGS_SIZE and i could fix the thread with
> > esp and eip by exception handler UTCB. And the thread could start with
> > new instruction pointer and new stack pointer. But it still has some
> > problem when the thread quit from new function. So i want to know how an
> > thread is resumed by exception reply. I mean which part of code in kernel
> > could finish the thread wakeup. I read the receive.c but i don't find it.
>
> The function copy_utcb_to_ts copies the state from the utcb of the
> exception handler over the state of the thread. The thread then resumes
> with this new state. I think what you have to do is to e.g. prepare the
> stack of the thread in a way that when the new function's ret is
> called it resumes at the position it was intercepted. Is this possible?
Hello, Adam:
Now the demo could work according to your design. And this demo is so simple only to emulate the situation we talked about before. I introduced a little about this demo:
3 threads: timer_thread, exception_thread, main_thread
main_thread emulates the behaviour of system which is a endless loop to output. the function body is thread_func1.
timer_thread emulates the behaviour of timer thread which could trigger the exception periodically.
exception_thread emulates the behaviour of handling interrupt. The function body is exception_handler.

When the timer_thread modify the status of main_thread with flag L4_THREAD_EX_REGS_RAISE_EXCEPTION. The main thread will be suspend and the exception_thread could get the exception ipc from main_thread. Exception_thread will modify the ESP and EIP in the utcb and then reply to main thread. The main thread will resume to the function about handling interrupt. When the handling interrupt function is over. The main thread could go back to the status before the exception happens.
The output:
count 49
...
count 58
id: 8:1, 12 0xeacff011 15 0x100711c
do irq 0
...
do irq 9
l4_sleep(): IPC error 00
count 59
...
count 67
id: 8:1, 12 0xeacff011 15 0x100711c
The output between "count ..." is execution of main thread. The output between "do_irq ..." is execution of exception thread which emulates the interrupt handling.

BUT. I have a problem about my code when i fixing the stack of main thread. The correct code which could work well is like this:
utcb = l4_utcb_get();
eip = utcb->exc.eip;
esp = utcb->exc.esp;
utcb->values[12] = (l4_umword_t)(do_irq);
esp_loc = 1024 - (esp - (l4_umword_t)stack)/4;
stack[esp_loc - 1] = eip;
l4_msgtag ...
l4_ipc_send_tag
In the code above i only reset the next stack with return address (old eip). But it seems i can't reset the new stack pointer like
utcb->values[15] = esp - 4
In my opinion it should do but if i did it can't work. It seems some tricky here. Can you tell me why it is like this?
Additinally, i tried this way about handling interrupt with interrupt number like this:
void do_irq(int irq)
it can't work either.

Thanks.
Cheng Guanghui