dyer@spdcc.COM (Steve Dyer) (04/17/87)
I have NEVER been able to figure out how to get a large model
program working reliably even with the SCO beta-test C release.
Sometimes it seems like a black art without any discernable rules.
I have several questions:
Is the -F 0xxxx flag which can be given both to "cc" and "ld" used only by
the loader or does the compiler itself use this too? My guess would be
the loader only; otherwise, the standard libraries would have to be special-
cased. If this is so, then is it permissible to play around with
"fixhdr -F 0xxxx x.out" increasing the stacksize as necessary?
What exactly does the 'd' flag do in "cc", as in "cc -Mld ...".
There is only the vaguest allusion to this in the manual page;
it says "instructs the compiler not to assume SS=DS." When would
this be used? I would assume that SS<>DS in any large model program.
I'm trying to bring up MH-6.5, a system which unfortunately assumes
too much about the machine it's running on and defines gratuitously
large (in 8086 terms) automatic arrays. Naturally, this is guaranteed
to cause a stack overflow, at least with the default stack allocation. Now,
before I started taking a machete to the code, I figured that if you
have a program compiled in large model, you would have 64K of stack
to play around with. However, I've found that setting the stack size
to anything reasonable is as likely to produce a 'too big' error (ENOMEM),
but the exact value of the stacksize which causes this depends on the
individual program. Exec's return of ENOMEM in the case of a stacksize
problem isn't documented anywhere, nor it is clear whether it can be
worked around or what it really means (I mean, I've got 4 damn megabytes
on this machine, 10 meg of swap space, and an executable smaller than
100K which doesn't even have a chance to do any mallocs.) What ARE the
rules in this situation? It's hard to know which is grosser--the 286
architecture or the poorly documented and supported tools in Microsoft
Xenix to use the architecture.
--
---
Steve Dyer
dyer@harvard.harvard.edu
dyer@spdcc.COM aka {ihnp4,harvard,linus,ima,bbn,halleys}!spdcc!dyer