Re: [elysium-developers] PCT

[Kasper V. L. <ve...@da...>]

> Well I'm stuck again ;(

Okay - let's see...
 
> In t2 (the test program that currently does a PCT to t1) the asm code for
> sys_pct is thus:
> 
> sys_pct:
>         movl    $0x55,%ecx
>         movl    4(%esp),%eax
>         movl    $0x58,%ecx
>         pushl   sys_pct_after
>         movl    $0x59,%ecx
>         pushal
>         movl    $0x62,%ecx
>         pushf
>         movl    $0x60,%ecx
>         movl    %esp, _crt0_saved_sp
>         movl    $0x61,%ecx
>         movl    $0x57,%ecx
>         int     $0x47

What's your strategy? Do you intend to let the called process return?
When I did the IRQ handling stuff I made a mistake that produced strange
results. I ran the IRQ handling process with _process_run() which
changes the address space (by changing CR3), but on return I didn't
change back. 
 
> The prototype is:
> void sys_pct (int pid);

Fine.

> All the movl    $xx,%ecx are debugging
> t2 crashes with ECX=59 everytime (and I've put delay loops in to check it isn't
> a timing thing).
> 
> CS = 0x1b
> DS = 0x23
> SS = 0x00100023
> (that 1 is there again, but pushl sys_pct_after works...)
> EIP= 0xc35832eb
> ESP= 0x10001d0c
> (there's room on the stack yet)

I'm really worried about the SS = 0x00100023 - could you send me the
code? I want to investigate :-)
 
> It must be that pushal crashing I think (because if it ever finished ECX would
> change). But how does EIP go so wonkey?

It's easy to mess up EIP - if you fail to maintain the stack properly a
single 'ret' instruction will certainly do something like that.

/Kasper

BTW: Let's make a debug system call (interrupt 3 would do fine) and let
that dump some basic CPU information. That would be useful instead of
the movl $xx,%ecx stuff :-)