Okay... I'm starting to see the light... :) I see that the new thread
gets a new %esp value from copy_thread... but I still don't understand the
registers on entrance to the int 80! :)
-Chris
On Fri, 7 Jul 2000, Chris Lattner wrote:
>
> Okay, this really has me stumped. :) I'm trying to figure out how
> kernel_thread could possible work. Here's the code for it [truncated]:
>
> int kernel_thread(int (*fn)(void *), void *arg, unsigned long flags) {
> long retval, d0;
>
> __asm__ __volatile__(
> "movl %%esp,%%esi\n\t"
> "int $0x80\n\t" /* Linux/i386 system call */
> "cmpl %%esp,%%esi\n\t" /* child or parent? */
> "je 1f\n\t" /* parent - jump */
>
> /* do child stuff here */
>
> "1:\t"
> :"=&a" (retval), "=&S" (d0)
> :"0" (__NR_clone), "i" (__NR_exit),
> "r" (arg), "r" (fn),
> "b" (flags | CLONE_VM)
> : "memory");
>
> Which seems to make sense... we're using sys_clone to do the work. The
> problem is that when it's compiled by gcc, I get code like this:
>
> 0x1006d584 [kernel_thread]: pushl %ebp
> 0x1006d585 [kernel_thread+0x1]: movl %esp,%ebp
> 0x1006d587 [kernel_thread+0x3]: pushl %esi
> 0x1006d588 [kernel_thread+0x4]: pushl %ebx
> 0x1006d589 [kernel_thread+0x5]: movl 8(%ebp),%edx
> 0x1006d58c [kernel_thread+0x8]: movl 16(%ebp),%ebx
> 0x1006d58f [kernel_thread+0xb]: orb $0x1,%bh
> 0x1006d592 [kernel_thread+0xe]: movl $0x78,%eax
> 0x1006d597 [kernel_thread+0x13]: movl 12(%ebp),%ecx
> 0x1006d59a [kernel_thread+0x16]: movl %esp,%esi
> 0x1006d59c [kernel_thread+0x18]: int $0x80
> 0x1006d59e [kernel_thread+0x1a]: cmpl %esp,%esi
> 0x1006d5a0 [kernel_thread+0x1c]: je 0xc <1006d5ae>
> ...
>
> So the "newesp" argument is getting set to 12(%ebp) which is the 'arg'
> parameter to the kernel_thread. Okay, this is wierd. On other platforms
> [sparc] it gets set to 0, which is fine because clone assumes you want to
> return on the same stack that you left on... that's fine as well, except
> that the 'cmpl %esp,%esi' would seem to preclude returning on the same
> stack. Why isn't %eax checked for the return value of clone?
>
> This is very mysterious code... and maybe my version of gcc is not happy,
> but I could swear nothing says to set ecx to 0... and when it does get to
> zero, how does kernel_thread know that it should allocate a new stack for
> the process? (which is what I assume is the only possible thing to do...)
>
> Thanks all,
>
> -Chris
>
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jul 07 2000 - 15:52:19 EDT