Path: utzoo!mnetor!uunet!husc6!hao!oddjob!gargoyle!ihnp4!ihlpa!dhp
From: dhp@ihlpa.ATT.COM (Douglas H. Price)
Newsgroups: comp.unix.xenix
Subject: @#$%*#@&$!!! SEGMENTS!
Message-ID: <6596@ihlpa.ATT.COM>
Date: 21 Dec 87 16:46:03 GMT
Organization: AT&T Bell Laboratories - Naperville, Illinois
Lines: 53
Keywords: SCO Xenix 2.1.1 stack segment limitations

Well folks, THE PROBLEM rears its ugly head again.  I am attempting to bring
up elm 1.7 under xenix, and the usual 286 difficulties have occurred.

Flame 1.  Here is another example of the-world-is-a-vax code.  As much as I
	like flat address spaces, I accept the existence of non-flat address
	space machines (much like I am forced to accept the possibility of
	nuclear war).  Moral:   USE LINT!  Integers are not necessarily the
	size of pointers!

Flame 2.  The stack is allocated in the same segment as static data in large
	model!  This is penny-wise and pound-foolish.  Sure is speeds up execution,
	but only if you have enough stack space left over to run the program
	at all! 

        Flame 2a.  I know, I KNOW we have talked about this before, but why didn't
		INTEL make the 286 architecture so that you could FAKE a larger
		linear addres space by making segment addressing contiguous!  It
		would have saved us all alot of headaches.  As it is, even if you
		had an entire 64K of stack, many existing programs would still
		bite the dust for lack of stack space!

So, we come to the question:  How do I allocate the stack in a separate segment
so that it has room to grow?  Elm uses up too much of the static segment as
it is to permit the stack and static data to coexist.

I have tried:

/bin/ld -P:	Normally, alike named segments are packed into as few physical
		segments as possible.  The -P option disables this.  There are
		approximately 40 modules in elm, so I ended up with 40 sparsely
		populated TEXT segments.  The DATA segements were not affected.
		Dead end.

cc -ND _DATA2	This  resets the name of the default data segment to _DATA2.
		It built correctly, but the program blew up with a segment 
		violation in the first system library routine executed (getenv()).
		Apparently, this breaks down due to the Flame 2 assumption that
		DS register == SS register in the compiled library code.
		
cc -M2ld	The Md option disables the DS == SS assumption in the compiled
		code.  But, it turns out that for some reason it is mutually
		exclusive with the -ND option above.  /bin/cc will refuse to
		accept it.

I assume that I might be able to play some game with the location of the stack
through the use of declarations in the assembler, but I suspect I am going to
be shot in the foot by /lib/libc no matter what I do.  Suggestions?

-- 
						Douglas H. Price
						Analysts International Corp.
						@ AT&T Bell Laboratories
						..!ihnp4!ihlpa!dhp