From owner-freebsd-current  Thu Feb  1 02:07:33 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id CAA13654
          for current-outgoing; Thu, 1 Feb 1996 02:07:33 -0800 (PST)
Received: from Root.COM (implode.Root.COM [198.145.90.17])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id CAA13647
          for <current@FreeBSD.org>; Thu, 1 Feb 1996 02:07:27 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by Root.COM (8.6.12/8.6.5) with SMTP id CAA01314; Thu, 1 Feb 1996 02:07:28 -0800
Message-Id: <199602011007.CAA01314@Root.COM>
X-Authentication-Warning: implode.Root.COM: Host localhost didn't use HELO protocol
To: KATO Takenori <kato@eclogite.eps.nagoya-u.ac.jp>
cc: current@FreeBSD.org
Subject: Re: TSS broken 
In-reply-to: Your message of "Mon, 01 Jan 1996 11:50:18 +0900."
             <199601010250.LAA00929@marble.eps.nagoya-u.ac.jp> 
From: David Greenman <davidg@Root.COM>
Reply-To: davidg@Root.COM
Date: Thu, 01 Feb 1996 02:07:28 -0800
Sender: owner-current@FreeBSD.org
Precedence: bulk

>In recent change of sys/i386/i386/swtch.s, the code
>	movl	%esp,PCB_ESP(%ecx)
>is changed into
>	leal	4(%esp),%eax
>	movl	%eax,PCB_ESP(%ecx)
>(in savectx).
>
>After this operation, the member tss_esp points not user stack
>pointer, but the address of TSS.
>
>This may causes panic when swapper is activated.

   I don't think so. At the time of entry to this function, the stack pointer
points to the return address of the caller that was saved on the stack when
the call was made. The stack layout looks like this:

...
address of caller (?)
auto variables used in mi_switch
arguments to cpu_switch (proc)
address of caller (mi_switch)
auto variables used in cpu_switch
arguments to savectx (pcb)
address of caller (cpu_switch)

   The instruction pointer that is saved is the caller of savectx(), which is
in cpu_switch. When the new process is scheduled to run, it will start at the
return address. Previously, the stack was not fixed up to remove the return
address and the result was that it was off-by-four. If cpu_switch referenced
any of it's auto variables when the child started, bad things would have
happened. The messed up stack pointer wasn't normally a problem because none
of the auto variables were referenced after 'returning' to cpu_switch and the
frame pointer fixes up the stack before the return to mi_switch.

-DG

David Greenman
Core Team/Principal Architect, The FreeBSD Project