Re: ELKS executable, time for a change?

[Harry Kalogirou <harkal@gmx.net>]

[Forwarded Message]

From: Al Riddoch <alriddoch@zepler.org>
To: Harry Kalogirou <harkal@gmx.net>
Subject: Re: ELKS executable, time for a change?
Date: 28 Oct 2002 12:19:18 +0000

On Mon, Oct 28, 2002 at 02:14:11PM +0200, Harry Kalogirou wrote:
> 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?
> 

I'm afraid I don't have a copy of the sources or docs to hand, so I can't
immediatly look up what I wrote. I seem to remember that the
restricted stack was something that we would just have to live with in
the scheme devised, though it is possible you could allocate holes
for the data segment which do not start at 0x0, and then re-alocate the
data segment to a new hole with a lower start address if the stack
gets too big.

Al
(who has recently been discovered not to be dead)