I dont know if you understood my doubt, but your pointer to bp accidentally or otherwise solved the mystery. The problem was although switch_to changes esp to the next processes stack, code emitted by the compiler, has "cached" the 'prev' processes's esp via ebp, and uses this at return to restore... So in effect, esp would again get changed to prev's esp. switch_to is a MACRO and saves ebp on stack and restores it. The above ensures that the cached ebp is also changed to the next's cached ebp, in some sense. I removed the push %ebp , and pop %ebp from switch_to and ran and it promptly crashed. But with -fomit-frame-pointer, all this does not take place. Still, could some one enlighten me on why esi and edi are also similarly saved and restored ? -----Original Message----- From: Jamie Lokier <[EMAIL PROTECTED]> To: Parity Error <[EMAIL PROTECTED]> Date: Mon, 19 Mar 2001 15:04:25 +0100 Subject: Re: switch_to()/doesnt %esp get replaced with %ebp on ret = =That's not nice code from the compiler (suboptimal), but it'll work. =leal -24(%ebp),%esp is perfectly ok in the epilogue of a function. =You're right that %esp is lost -- in this case, %ebp has effectively the =same information. = =Think like this: a perfectly normal function (without switch_to) can =have this: = =f: pushl %ebp = movl %esp,%ebp = pushl %ebx = ... do stuff, decrement %esp a lot to call functions etc. etc. ... = movl -4(%ebp),%esp = popl %ebx = popl %ebp = ret = =Parity Error wrote: => in schedule(), switch_to() macro changes esp to => the new process's stack. But, on exit frm schedule, => how come it does not get overwritten with ebp-24, => as the dissasembled code shows. The code was compiled => without the -fomit-frame-pointer. => => pushl 508(%ecx) => jmp __switch_to => 1: popl %ebp => popl %edi => popl %esi => => jmp .L1180 => => .L1180: => leal -24(%ebp),%esp => popl %ebx => popl %esi => popl %edi => movl %ebp,%esp => popl %ebp => ret = - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/