From mboxrd@z Thu Jan  1 00:00:00 1970
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: Re: ELKS executable, time for a change?
Date: 28 Oct 2002 13:08:16 +0000
Sender: linux-8086-owner@vger.kernel.org
Message-ID: <1035810496.2067.7.camel@irongate.swansea.linux.org.uk>
References: <1035807219.5492.84.camel@cool>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Return-path: <linux-8086-owner@vger.kernel.org>
In-Reply-To: <1035807219.5492.84.camel@cool>
List-Id: <linux-8086.vger.kernel.org>
Content-Type: text/plain; charset="us-ascii"
To: Harry Kalogirou <harkal@gmx.net>
Cc: Linux-8086 <linux-8086@vger.kernel.org>

On Mon, 2002-10-28 at 12:14, Harry Kalogirou wrote:
> Also I would like to ask Al if he can explain how was he planning to
> support an enlarging stack? This is mentioned in mm/malloc.c. I
> personaly don't see a way for this to happen. Am I missing something?

If you have code to detect stack overflows then you can do it with a bit
of compiler help. It makes things a lot more expensive so I question
whether it should be done.

Basically your entry code starts to look like

function_entry:
	if(new frame wont fit on stack)
	{
		alloc new stack segment
		push old esp to new stack
		push args to new stack
		call function_entry
		fix stack
		pop old stack segment
		free newer stack segment
		ret
	}