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.edudat@noao.edu (D'Anne Thompson) (06/22/91)
My problem module is no longer a problem, thanks to Mark Peek and Jwahar R. Bammi. Mark sent me the notice from Jwahar that he had seen some time ago. The VxWorks gnu toolkit that we received, uses gas-1.34. A co-worker already had gas-1.38, so I applied the patches from jwahar and our problem seems to be taken care of. Here is Mark's note to me, along with Jwahar's patches. > >I had a similiar thing happen in about the same environment. Attached is >a patch file with some bug fixes for gas. The one for expr.c seemed to do >the trick. If this works, go ahead and repost the answer. I can only take >credit for saving this article... > >Mark >---- > >Name: Mark Peek >Mail: Imagen Division, QMS Inc. > 2650 San Tomas Expressway, P.O. Box 58101 > Santa Clara, CA 95052-8101 >AT&T: (408) 986-9400 >UUCP: mark@imagen.com or ...{decwrl,sun}!imagen!mark Here is Jwahar R Bammi's patches to gas-1.38... =========================================================================== Article 113 of gnu.utils.bug: Path: imagen!sun!newstop!sun-barr!apple!usc!zaphod.mps.ohio-state.edu!magnus.ircc.ohio-state.edu!tut.cis.ohio-state.edu!UUNET.UU.NET!cadence!bammi%acae127 From: cadence!bammi%acae127@UUNET.UU.NET (Jwahar R. Bammi) Newsgroups: gnu.utils.bug Subject: gas v1.38 bug + suggested fix Message-ID: <BAMMI.91Feb8161638@acae127.cadence.com> Date: 8 Feb 91 21:16:38 GMT Sender: daemon@tut.cis.ohio-state.edu Distribution: gnu Organization: Cadence Design Systems Lines: 162 Approved: bug-gnu-utils@prep.ai.mit.edu here are some of my fixes for gas 1.38 (and any m68k host): the problem was that AOFF mode was always generating 0 offsets, the following example #APP .text movew d1,a0@(two-one) .lcomm one,2 .lcomm two,2 was being assembled as "movew d1,a0@(0)" the diffs below incorporate the following: - diffs from kivinen@JOKER.HUT.FI (Tero Kivinen) fixing a6@(label) being assembled as PC relative rather than A6 relative. - diffs from ntmtv!thompson@AI.MIT.EDU (Mike Thompson) for "bkpt #0" - diff to expr.c: this requires a little explaination. the if condition at around line 530 in v1.38 reads if (expressionP -> X_subtract_symbol == expressionP -> X_add_symbol || ( expressionP->X_subtract_symbol->sy_frag==expressionP->X_add_symbol->sy_frag && expressionP->X_subtract_symbol->sy_value==expressionP->X_add_symbol->sy_value)) several people have pointed out that this causes seg. faults and needs to be patched to if (expressionP -> X_subtract_symbol == expressionP -> X_add_symbol || (expressionP->X_subtract_symbol && expressionP->X_add_symbol && expressionP->X_subtract_symbol->sy_frag==expressionP->X_add_symbol->sy_frag && expressionP->X_subtract_symbol->sy_value==expressionP->X_add_symbol->sy_value)) but doing so always produces zero for expressions such as ``a6@(two-one)''. (see the #def of "isvar" in m68k.c and its usage for example in the AOFF case at around line 1509 of m68k.c) , so the correct condition seems to be just if (expressionP -> X_subtract_symbol == expressionP -> X_add_symbol) (as it was in gas 1.34). with the patches suggested below, it seems to do much better. --- *** ../gas-1.38/expr.c Fri Jan 4 13:13:00 1991 --- expr.c Tue Feb 5 18:48:54 1991 *************** *** 527,535 **** * It is faster to re-cancel them to NULL * than to check for this special case. */ ! if (expressionP -> X_subtract_symbol == expressionP -> X_add_symbol ! || ( expressionP->X_subtract_symbol->sy_frag==expressionP->X_add_symbol->sy_frag ! && expressionP->X_subtract_symbol->sy_value==expressionP->X_add_symbol->sy_value)) { expressionP -> X_subtract_symbol = NULL; expressionP -> X_add_symbol = NULL; --- 527,533 ---- * It is faster to re-cancel them to NULL * than to check for this special case. */ ! if (expressionP -> X_subtract_symbol == expressionP -> X_add_symbol) { expressionP -> X_subtract_symbol = NULL; expressionP -> X_add_symbol = NULL; *** ../gas-1.38/m68k.c Tue Dec 4 15:50:00 1990 --- m68k.c Wed Feb 6 09:52:38 1991 *************** *** 1258,1265 **** long t; t=get_num(opP->con1,80); ! if(t<1 || t>8 || isvar(opP->con1)) ! losing++; } break; --- 1258,1271 ---- long t; t=get_num(opP->con1,80); ! if (s[1]!='s') { ! if(t<1 || t>8 || isvar(opP->con1)) ! losing++; ! } ! else { ! if(t<0 || t>7 || isvar(opP->con1)) ! losing++; ! } } break; *************** *** 1474,1480 **** if( !issword(nextword) || ( isvar(opP->con1) && ( ( opP->con1->e_siz==0 ! && flagseen['l']==0) || opP->con1->e_siz==3))) { if(opP->reg==PC) --- 1480,1486 ---- if( !issword(nextword) || ( isvar(opP->con1) && ( ( opP->con1->e_siz==0 ! && flagseen['l']!=0) || opP->con1->e_siz==3))) { if(opP->reg==PC) *************** *** 1489,1495 **** break; } else { addword(0x0170); ! add_fix('l',opP->con1,1); } } else addword(0x0170); --- 1495,1501 ---- break; } else { addword(0x0170); ! add_fix('l',opP->con1,0); } } else addword(0x0170); *************** *** 1976,1984 **** break; case 'Q': ! tmpreg=get_num(opP->con1,10); ! if(tmpreg==8) ! tmpreg=0; install_operand(s[1],tmpreg); break; --- 1982,1997 ---- break; case 'Q': ! if (s[1]!='s') { ! tmpreg=get_num(opP->con1,10); ! if(tmpreg==8) ! tmpreg=0; ! } ! else { ! tmpreg=get_num(opP->con1,20); ! if(tmpreg==8) ! tmpreg=0; ! } install_operand(s[1],tmpreg); break; cheers, -- bang: uunet!cadence!bammi jwahar r. bammi domain: bammi@cadence.com GEnie: J.Bammi CIS: 71515,155 -- D'Anne Thompson National Optical Astronomy Observatories P.O. Box 26732 Tucson, AZ 85726