trygg@nososl.UUCP (Trygg A. Eliassen) (06/12/91)
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 compiler and compiling some files I get the following message from the compiler before it dies, no files are produced. %ls -l geometry.c %-rwxrwx--- 1 1001 26096 May 30 14:36 geometry.c % %make geometry.o % %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. *** Error code 1 make: Fatal error: Command failed for target `geometry.o' % Does anybody have an idea. Thanks -- Trygg A. Eliassen BSc. Hons | trygg@nordic-offshore.no Nordic Offshore Systems AS | mcsun!nuug!nososl!trygg Stabekk - Oslo - NORWAY | Tlf +472 12 55 80 Fax +472 12 54 01
healy@cod.NOSC.MIL (Mike Healy) (06/13/91)
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 >compiler and compiling some files I get the following message from the compiler before it dies, no files are produced. > . . . (stuff deleted) >cc68k: Program as got fatal signal 11. >*** Error code 1 >make: Fatal error: Command failed for target `geometry.o' >% >-- ... (stuff deleted) >Trygg A. Eliassen BSc. Hons | trygg@nordic-offshore.no >Nordic Offshore Systems AS | mcsun!nuug!nososl!trygg >Stabekk - Oslo - NORWAY | Tlf +472 12 55 80 Fax +472 12 54 01 I had the exact same problem, but only with one file. When this file was compiled on a SPARCStation at our customer's site, it would get this error numerous times before succeeding. Finally, after as many as 10 or 12 attempts, it would compile successfully. None of the other modules (~ 100 files) had this problem. This never happened at our lab using a Sun 3/60 and the same vxWorks/gcc (cc68k). At first I thought that maybe there was a bad spot on the disk where the file was located, but in the course of development this file was moved to several different disks and the problem didn't change. My solution is that the system is installed and that particular module no longer needs to be compiled 8^) , but if you find out what's going on, please email me or post. I think the code is forcing the assembler into a little-used (and not completely debugged) path. Or you could try compiling it on an old Sun 3 8^) BTW, our targets are FORCE CPU-30s running vxWorks. I am happy with vxWorks. Some of our needs are not supported by Wind River (e.g. raw ethernet datagram multicasting), but they have been very nice about giving me the source so I could get the job done. Mike Healy ETA Technologies healy@cod.nosc.mil
dat@noao.edu (D'Anne Thompson) (06/13/91)
We just encountered the same problem about 4 hours before the net message
arrived. Our situation is this:
System was just moved from a Sun3/80 host using native SUN compiler, to
a Sparc SLC host using VxWorks GNU Toolkit.
We recompiled over 250 modules using cc68k before encountering this one.
Error message is "as exits with signal 11". Core dump is 8,65x,xxx bytes.
Problem is with a single module. All other modules (>300) compiled first
time and every time.
Using cc68k -S generates a good looking assembly output file that assembles
just fine using as68k. (Repeated sequences of cc68k -S and as68k worked
everytime).
In trying repeated attempts to use a normal cc68k -c sequence, it took
12 tries before success. Continued efforts had the same results, about
1 success in 12 tries.
Perhaps this helps.
D'Anne Thompson
National Optical Astronomy Observatories
P.O. Box 26732
Tucson, AZ 85726
(602) 325-9335
dat@noao.edu {...}!uunet!noao.edu!dat
--
D'Anne Thompson
National Optical Astronomy Observatories
P.O. Box 26732
Tucson, AZ 85726trygg@nososl.UUCP (Trygg A. Eliassen) (06/14/91)
In article <1991Jun13.165043.27505@noao.edu> dat@noao.edu (D'Anne Thompson) writes: >Using cc68k -S generates a good looking assembly output file that assembles >just fine using as68k. (Repeated sequences of cc68k -S and as68k worked >everytime). > I will try to do it in 2 steps to see if that works, I had a letter from Bradley White suggesting the stacksize limit in the C-shell. I bumped it up to max, but I had no luck. It compiles now and then. >In trying repeated attempts to use a normal cc68k -c sequence, it took >12 tries before success. Continued efforts had the same results, about >1 success in 12 tries. Is the code generated OK ? -- Trygg A. Eliassen BSc. Hons | trygg@nordic-offshore.no Nordic Offshore Systems AS | mcsun!nuug!nososl!trygg Stabekk - Oslo - NORWAY | Tlf +472 12 55 80 Fax +472 12 54 01
jclark@sdcc6.ucsd.edu (John Clark) (06/21/91)
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