From mboxrd@z Thu Jan 1 00:00:00 1970 From: Harry Kalogirou Subject: ELKS executable, time for a change? Date: 28 Oct 2002 14:14:11 +0200 Sender: linux-8086-owner@vger.kernel.org Message-ID: <1035807219.5492.84.camel@cool> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: List-Id: Content-Type: text/plain; charset="us-ascii" To: Linux-8086 Hi all, Lately I desided that the fact that processes come with a fixed data segment, is quite restrictive. So I tried to solve that. I studied the work that Al did on this before and came to the conclution that indeed the only memory setup that will allow us to expand the data segment is this (from the Documentation/text/bin-formats.txt) : +-----------------+------------+----------------+ | | <--- stack | data + bss | heap ---> | | < current->t_endseg +-----------------+------------+----------------+ ^ ^ ^ 0x0 current->t_enddata current->t_endbrk This is mainly because bcc assumes ds == ss. So we can't move the stack at the end of the data segment everytime sys_brk() instructs us to enlarge it. It is obvious that with this setup we will have a freely expandable heap, while the stack will be fixed. So : 1) We need the linker to define the stack space at compile time. 2) Since ds==ss, the linker whould create executable with the data segment pointers offseted by the stack size. As Al says in the bin-formats.txt file, we can use the -D linker option to give the data offset. The main problem now if that we can't tell if and how much offset an executable has, or equaly what stack the executable needs. We probably need to change the linker to produce a new executable format, a custom format for ELKS. What are your thoughts on this? 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? Harry