dennis@rlgvax.UUCP (Dennis Bednar) (03/20/86)
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 UUCPbaron@transys.UUCP (Joe Portman) (03/24/86)
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!/
frodo@wcom.UUCP (Jim Scardelis) (03/25/86)
> > MicroSoft, Santa Cruz Operations, are you listening? > SCO's net address is ihnp4!sco. -- Jim Scardelis, SA {hjuxa,ihnp4}!wcom!frodo #include <favorite disclaimer>
caf@omen.UUCP (Chuck Forsberg WA7KGX) (03/26/86)
In article <177@transys.UUCP> baron@transys.UUCP (Joe Portman) writes: >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. >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). That implies you have a C compiler with a working large model. I have yet to see a Xenix large model that can compile the average non trivial program without an extreme amount of hacking to avoid compiler bugs. I eagerly await such a Xenix compiler, but am not holding my breath.
baron@transys.UUCP (03/28/86)
In article <316@omen.UUCP> the author writes: > In article <177@transys.UUCP> baron@transys.UUCP (Joe Portman) writes: > >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. > >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). > That implies you have a C compiler with a working large model. I have yet > to see a Xenix large model that can compile the average non trivial program > without an extreme amount of hacking to avoid compiler bugs. I eagerly > await such a Xenix compiler, but am not holding my breath. I will probably get flames for this, but here goes: I have been using the C compiler from SCO for since October 1985, (first release date ). I have had NO problems with it IF I follow standard conventions: IE, do not have a cavalier attitude toward pointers and integers. So far, none of the programs ported by me have had any major surgery, except you MUST watch your declarations. That's it. I can gripe about the compiler being slow :-), but I cannot say it does not work. As for a non-trivial program, how about vnews. Over 100k compiled. -- **************************************************** * 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!/