🚀 go-pugleaf

In <948@rlgvax.UUCP> Dennis Bednar writes:

> 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


I have run across this exact problem, notably with compiling and setting up
the usenet software.

I solved it by:

1.	using the -M2l and -s -i flags of the compiler. This sets the compiler 
	to LARGE memory model and enables 286 code generation. It also allows
	multiple data segments. The -s strips the symbol table and the
	-i says SEPARATE instruction and data space. This is implied in
	middle, large and huge models, but MUST be specified in the default
	model (small).

2.	Using the -F xxxxx option of fixhdr to change the stack size.
	or
	using the -F xxxxx option of the linker.


If this does not work ( you are not mentioning what size model you are
using), you can contact SCO directly at:

ihnp4!sco!support
 
Hope this helps all you XENIX SYS_V hackers.


-- 
          ****************************************************
          *        These are my own opinions, not those of   *
          *            my employer (self), or any one        *
          *           connected with the company (mine)      *
          ****************************************************

Joe Portman (SA)                                USPS: TransSystems Incorporated
AT&T: 1-206-453-5560                                  1280 116th Avenue NE
                                                      Bellevue WA 98009
              /-- uw-beaver!\         /-- camco!  \
... ihnp4! --<               >-tikal!<             >-- transys!root
              \-- microsoft!/         \-- teldata!/