ELKS executable, time for a change?

ELKS executable, time for a change?

[Harry Kalogirou]

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

Re: ELKS executable, time for a change?

[Alan Cox]

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
	}

Re: ELKS executable, time for a change?

[Harry Kalogirou]

> 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
> 	}
> 
> 

Well, I think I can live with the fixed stack then!

Harry

Re: ELKS executable, time for a change?

[Harry Kalogirou]

> 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.
>

Do you mean moving the "offset" at which the actual data starts in the
segment? Wouldn't that require a recompile of the program?
 
> Al
> (who has recently been discovered not to be dead)

!!!!!!! 

Harry

Re: ELKS executable, time for a change?

[Harry Kalogirou]

[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)