🚀 go-pugleaf

It does not seem possible to tell the Xenix SV compiler/loader for
the IBM PC/AT (286 CPU)to build an a.out with a large enough stack
segment in some cases.

While the documentation says that the absence of the -F cc flag
instructs the compiler to start the stack at the top of a full
64k byte segment, we have discovered that running programs under
control of adb show this to be false. Rather, if you omit the -F
cc flag to the compiler, the exec() somehow assigns the initial
stack pointer at approximately 4096 bytes greater than the end
of data. However, if you try to use a rather large hexidecimal
value for the -F flag to get around the problem, then sh complains
"a.out: too big" (actually its the exec() call failing,
errno == ENOMEM, not enough core).  Its not a problem of not
enough swap space, because we can recreate the "too big" error
on a simple stack.c test program that works for small values
of the -F flag.

We have also tried the documented cc -Md flag to tell the compiler
to assume that SS != DS.  That did not do any good.

We have also tried rewriting an assembly language version of
the _start.o C startup code found in /lib/Llibc.a (this is the
large model version of the C library), but found that the protection
mechanism on the 286 prevents our explicit loading of the ss
stack segment register.

We have also tried "patching" /lib/Lseg.o to (1) remove STACK from the
GRPDEF record, and (2) changing the Combine attribute for the STACK
SEGDEF record into an "Uncombinable".  We had hoped that we would
have fooled the ld loader into not combining the STACK segment contiguous
with the DS segment. This also failed.

We have also briefly investigated the format of the a.out (Xenix
calls this the Segmented x.out format for the 286 CPU).  We were
looking for something in the a.out file which tells exec() what to load
the ss register initially with, but we could *NOT* find what we
were looking for.

In short, we cannot tell the compiler &
loader to give us a large enough stack to work with.

Any suggestions on how to solve the problem would be appreciated.

MicroSoft, Santa Cruz Operations, are you listening?


-- 
-Dennis Bednar
{decvax,ihnp4,harpo,allegra}!seismo!rlgvax!dennis	UUCP