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 32ALLOCA=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 44CCLIBFLAGS=-Bstatic -dn -gg 45