Return to x-sysv4 CVS log

Up to [Apple XNU] / GNUtools / cc / config / i860

Annotation of GNUtools/cc/config/i860/x-sysv4, revision 1.1.1.1

1.1       root        1: # The svr4 reference port for the i860 contains an alloca.o routine
                      2: # in /usr/ucblib/libucb.a, but we can't just try to get that by
                      3: # setting CLIB to /usr/ucblib/libucb.a because (unfortunately)
                      4: # there are a lot of other routines in libucb.a which are supposed
                      5: # to be the Berkeley versions of library routines normally found in
                      6: # libc.a and many of these Berkeley versions are badly broken.  Thus,
                      7: # if we try to link programs with libucb.a before libc.a, those
                      8: # programs tend to crash.
                      9: 
                     10: # Also, the alloca() routine supplied in early version of svr4 for
                     11: # the i860 is non-ABI compliant.  It doesn't keep the stack aligned
                     12: # to a 16-byte boundary as the ABI requires.
                     13: 
                     14: # More importantly however, even a fully ABI compliant alloca() routine
                     15: # would fail to work correctly with some versions of the native svr4 C
                     16: # compiler currently being distributed for the i860 (as of 1/29/92).
                     17: # The problem is that the native C compiler generates non-ABI-compliant
                     18: # function epilogues which cut back the stack (upon function exit) in
                     19: # an incorrect manner.  Specifically, they cut back the stack by adding
                     20: # the nominal *static* frame size (determined statically at compile-time)
                     21: # to the stack pointer rather than setting the stack pointer based upon
                     22: # the current value of the frame pointer (as called for in the i860 ABI).
                     23: # This can cause serious trouble in cases where you repeatedly call a
                     24: # routine which itself calls alloca().  In such cases, the stack will
                     25: # grow continuously until you finally run out of swap space or exceed
                     26: # the system's process size limit.  To avoid this problem (which can
                     27: # arise when a stage1 gcc is being used to build a stage2 gcc) you
                     28: # *must* link in the C language version of alloca() which is supplied
                     29: # with gcc to your stage1 version of gcc.  The following definition
                     30: # forces that to happen.
                     31: 
                     32: ALLOCA=alloca.o
                     33: 
                     34: # We build all stages *without* shared libraries because that may make
                     35: # debugging the compiler easier (until there is a GDB which supports
                     36: # both Dwarf *and* svr4 shared libraries).
                     37: 
                     38: # Note that the native C compiler for the svr4 reference port on the
                     39: # i860 recognizes a special -gg option.  Using that option causes *full*
                     40: # Dwarf debugging information to be generated, whereas using only -g
                     41: # causes only limited Dwarf debugging information to be generated.
                     42: # (This is an undocumented feature of the native svr4 C compiler.)
                     43: 
                     44: CCLIBFLAGS=-Bstatic -dn -gg

This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.