Xref: utzoo comp.realtime:1422 comp.lang.c:40286 comp.sys.m68k:2396 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!uunet!ogicse!ucsd!sdcc6!jclark From: jclark@sdcc6.ucsd.edu (John Clark) Newsgroups: comp.realtime,comp.lang.c,comp.sys.m68k Subject: Re: cc68k gnu crosscompiler SPARC/68k20 exits w signal 11 Message-ID: <20818@sdcc6.ucsd.edu> Date: 20 Jun 91 23:56:21 GMT References: <92@nososl.UUCP> Followup-To: comp.realtime Distribution: comp Organization: University of California, San Diego Lines: 33 In article <92@nososl.UUCP> trygg@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@ucsd.edu