i370 ELF patches for ESA/390

[linas@linas.org]

It's been rumoured that Richard Henderson said:
> 
> On Tue, Sep 07, 1999 at 12:22:05AM -0500, Linas Vepstas wrote:
> > Having the stack grow upwards as in MVS proved
> > untenable (within the context of the Linux kernel).
> 
> I'm very surprised to hear this.  For my own benefit, would you
> describe the problems you saw?

Well, I could be wrong, but ... When the linux kernel goes to load
an ELF executable, it puts argv, argc, envp at the very top of 
virtual memory (0xfffff000 in our case), and initializes the stack 
pointer to just below this.  The stack then immdiately tries to 
grow upwards, and bam end of story.

I did not see anythinging that was obviously adjustable that
would allow me to put the stack elsewhere in the virtual memory.
In fact it makes sense, its a very traditional model: the heap is 
in low mem and grows up, the stack is at high mem and grows down.
Hopefully they never meet in the middle. 

Putting the stack in low mem and letting it gow up is harder, because
it limits the size of maximum possible stack to a small number, in
particular limits the max size of allaca(). (since the stack would 
have to fit in some small space between text/data & heap).

One side benefit is that the elf stack no longer checks for room 
on the stack.  Instead it expects the OS to fault when the stack
gets out of bounds, and map a new page for more stack or whatever 
other corrective action.  This chops a bunch of cycles out of every 
subr call.

But .. if you're aware of some ELF flag bit or other thingy that
would tell the loader 'put stack in low mem not high mem', let me 
know. 

--linas