ELKS executable, time for a change?

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?