🚀 go-pugleaf

>	On a Sun 4/110, if you type "unlimit stack" and then any other
>command, you will end up in the monitor.  Not good.

There are many wonderful ways of watchdogging a 4/110, apparently; I think
some of them may be fixed in some dot-dot release. 

However, even on a machine other than a 4/110, if you type "unlimit stack"
and then almost any other command, you'll be in for a surprise.  The SunOS
"mmap" implementation, when not given an indication of where to place the
object being mapped in (i.e., when you give it a null pointer as the
address to which the object should be mapped, and don't use MAP_FIXED),
has to choose *some* place to put it.  Well, it starts putting things
right below the stack limit, and moves down from there; that keeps it from
colliding with the heap as it grows up, or at least delays the collision
as long as possible.

If you unlimit the stack, there isn't any "right below the stack limit"
any more, since there's no stack limit, so it just has to throw up its
hands in despair.

The run-time loader used for dynamically-linked programs will, when it
maps in shared libraries, not tell the kernel where it should put them; I
think the code in "crt0.o" that maps in the run-time loader does so as
well.  Thus, if you have no stack limit, none of these shareable images
can be mapped in, and thus you cannot run any dynamically-linked
images....

Since shareable images are relocated at run time (if compiled with "-pic",
not much relocation is needed, which cuts down on the number of pages
copied-on-write), proper operation of those images is not dependent on
where they're put in the address space.  Thus, while you can't unlimit the
stack and have dynamically-linked programs run, you can provide any finite
limit (that leaves room for the images, and anything else such as frame
buffers, etc., to be mapped in) and have the programs still work.