cc68k gnu crosscompiler SPARC/68k20 exits w signal 11

[John Clark]

In article <92 at nososl.UUCP> trygg at nososl.UUCP (Trygg A. Eliassen) writes:
+I have just received vxWorks 5.0 with the GNU toolkit.  We are running
+SPARC as host and MIZAR 68k20 targets.  I am compiling with the cc68k
+
+
+%cc68k -O -c -g -traditional -fvolatile -DCPU=MC68020 -DVX -I../../../prog/ins 
+-I../ins -I../../../prog/db/eff -I/local/vw/h -I../../../prog/db/ins geometry.c
+cc68k: Program as got fatal signal 11.

Try using the '-v' option. This will print a 'blow-by-blow'
sub-program execution. The signal 11 could be from 'cc68k', 'cpp',
'cc1-68k', 'as68k'. I have seen such on some "gcc's" when only the
'first' compilation cycle has been done, as in the case of the cross
compiler. It seems to be in relation to memory and dynamic
allocation.  The system 'swap' could be minimal and as gcc allocates
more than some size, given other task allocations, it bombs.

If the particular program which gives the signal is identified, use
'adb' to get a '$c' call trace back. If the signal comes from an
'abort' then some 'internal' compiler error was detected and gcc is
'ungracefully' exiting. If the fault location is not in 'abort' then
some other obnoxious thing has happend. Call Wind River. Or if you
didn't pay for the 'support' post to 'gnu.gcc.bug'.

When gcc(cc68k) executes at least 3 tasks are 'active', 'gcc'
background, 'cc1' compiler, 'gas(as68k)' receiving  the output of
'cc1'. One fellow noted that the 'core' file was 8Meg or so. This
may be a maximum for his system configuration. Virtual memory works
only if there's disk space virtually available.
-- 

John Clark
jclark at ucsd.edu