switch_to()/doesnt %esp get replaced with %ebp on ret

switch_to()/doesnt %esp get replaced with %ebp on ret

[Parity Error]

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

Re: switch_to()/doesnt %esp get replaced with %ebp on ret

[Jamie Lokier]

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

Re[2]: switch_to()/doesnt %esp get replaced with %ebp on ret

[Parity Error]

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 <lk@tantalophile.demon.co.uk>
To: Parity Error <bootup@mail.ru>
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
=

Re: switch_to()/doesnt %esp get replaced with %ebp on ret

[Jamie Lokier]

Parity Error wrote:
> I dont know if you understood my doubt, but your pointer
> to bp accidentally or otherwise solved the mystery. 

We agree, and I like your explanation.

> Still, could some one enlighten me on why esi and edi are
> also similarly saved and restored ?

The compiler _may_ cache other values in those registers across the call
to switch_to.  Although this doesn't happen in your kernel, it does
sometimes happen and switch_to must be coded to assume that it does.

You can safely remove the esi & edi pushes and pops, if you put those
registers in the "clobber" list of the asm.  In theory that's best,
because then the compiler will save the register values itself only if
it needs to.

In practice, putting them in the clobber list sometimes results in worse
code, at least when I tried this in the 2.2 series.

You can't put ebp in the clobber list for some reason: GCC silently
ignores it.  (Maybe that's fixed now too, I don't know).

-- Jamie