Return to BSD News archive
Newsgroups: comp.unix.bsd
Path: sserve!manuel!munnari.oz.au!spool.mu.edu!uwm.edu!caen!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: Motif1.1.3 prob. on FreeX86...
Message-ID: <1992Sep24.002056.17978@fcom.cc.utah.edu>
Sender: news@fcom.cc.utah.edu
Organization: Weber State University (Ogden, UT)
References: <yx8n2#_.kwan@netcom.com> <JTSILLA.92Sep23170623@damon.ccs.northeastern.edu>
Date: Thu, 24 Sep 92 00:20:56 GMT
Lines: 71
In article <JTSILLA.92Sep23170623@damon.ccs.northeastern.edu> jtsilla@damon.ccs.northeastern.edu (James Tsillas) writes:
>Are you running Motif on 386BSD? I assume you've done the port yourself.
>People have had success using Motif with XFree86 on SVR4. I haven't
>tried it on SVR3 (lacking the libraries). I would be strongly suspect of
>a port of Motif to 386BSD considering the problems one finds when
>porting it to SunOS.
The problem in porting is the Xt library, and within the Xt library, certain
constructs exist wherein a register lvalue is assigned the results of a
function of the varialble:
foo( cp)
{
char *cp = "xxxyyy"; /* register'ized by compiler*/
cp = func( cp);
}
The problem is called "the register pop order bug" and is a well known
prblem (at least in the circles I travel in) of the Berkeley-based C
compiler. The problem is that the assignment takes places before the
register contents (which are pushed prior to the function call) are
popped back into the variable.
You can declare "cp" as static, volatile (sometimes works) or move it out
of "foo" altogether. Alternately, adding "c++; c--;" before the "func"
line will also work around it.
The problem on 386BSD is in GCC. Static variables declared in functions are
treated as if "const" (placed in read-only pages). The following is an
example that illustrates this:
fee()
{
int once = 1;
if( once) {
once = 0; /* SIGSEGV*/
... stuff ...
}
}
This is under gcc 2.2.2.
There is also an optimizer problem similar to the pop-order problem, but it
appears to be related to common-subexpression elimination. Moving the
offending variable out of the function (as a static global) or declaring it
"auto" or "volatile" to prevent optimization to a register seems to get
aroungd the problem here as well.
VMS, whose C compiler is a derivitive of an old PL/1 compiler, uses
placeholders rather than statements in expression compilation, and has a
similar problem. One can turn off inlining of user functions using a
#pragma, or use the /NOOPT qualifier to get around the problem there.
Terry Lambert
terry_lambert@npd.novell.com
terry@icarus.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.
--
-------------------------------------------------------------------------------
"I have an 8 user poetic license" - me
Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------