Illegal instruction on sparc32-linux

Illegal instruction on sparc32-linux

[Thorsten Kukuk]

Hi,

If I compile C++ programs with the latest gcc 3.1 snapshots on 
sparc32-linux, some programs fails with "Illegal instruction".

This is reproduceable for me with groff, qt2 and qt3. Does anybody
else see this?

  Thorsten

-- 
Thorsten Kukuk       http://www.suse.de/~kukuk/        kukuk@suse.de
SuSE Linux AG        Deutschherrenstr. 15-19       D-90429 Nuernberg
--------------------------------------------------------------------    
Key fingerprint = A368 676B 5E1B 3E46 CFCE  2D97 F8FD 4E23 56C6 FB4B

Re: Illegal instruction on sparc32-linux

[Christian Jönsson]

On Thu, Apr 18, 2002 at 10:11:51PM +0200, Thorsten Kukuk wrote:
> 
> Hi,
> 
> If I compile C++ programs with the latest gcc 3.1 snapshots on 
> sparc32-linux, some programs fails with "Illegal instruction".
> 
> This is reproduceable for me with groff, qt2 and qt3. Does anybody
> else see this?

hmm, not I, might it be binutils related?

/ChJ

Re: Illegal instruction on sparc32-linux

[David S. Miller]

   From: Thorsten Kukuk <kukuk@suse.de>
   Date: Thu, 18 Apr 2002 22:11:51 +0200

   If I compile C++ programs with the latest gcc 3.1 snapshots on 
   sparc32-linux, some programs fails with "Illegal instruction".
   
   This is reproduceable for me with groff, qt2 and qt3. Does anybody
   else see this?

Can you put the program under GDB so we can see what the instruction
is that it is trapping on?

I'm not seeing this at all, but I only do testing on UltraSPARC boxes
for the sparc32 targets...

Re: Illegal instruction on sparc32-linux

[Thorsten Kukuk]

On Thu, Apr 18, David S. Miller wrote:

> 
>    From: Thorsten Kukuk <kukuk@suse.de>
>    Date: Thu, 18 Apr 2002 22:11:51 +0200
> 
>    If I compile C++ programs with the latest gcc 3.1 snapshots on 
>    sparc32-linux, some programs fails with "Illegal instruction".
>    
>    This is reproduceable for me with groff, qt2 and qt3. Does anybody
>    else see this?
> 
> Can you put the program under GDB so we can see what the instruction
> is that it is trapping on?

I tried it. But when I compile it with -g, I cannot reproduce it from
the shell or from gdb. But if I call "make", it fails again.
 
> I'm not seeing this at all, but I only do testing on UltraSPARC boxes
> for the sparc32 targets...

I also use a UltraSPARC for this. I compile groff and then run
"sparc32 make" in the groff/doc source directory and it fails
with:

export GROFF_TMAC_PATH; \
sed -e "s;@VERSION@;`cat ../VERSION``sed -e 's/^0$//' -e 's/^[1-9].*$/.&/' ../RE
VISION`;" pic.ms \
| ../src/roff/groff/groff -p -e -t -Tps -F../font -U -ms -mwww >pic.ps
../src/roff/groff/groff: troff: Illegal instruction

All other input files works fine. Same for uic from qt2 and qt3: If
I try to debug it, it works. And there are only a few input files
for which it fails, most input files works fine.

  Thorsten

-- 
Thorsten Kukuk       http://www.suse.de/~kukuk/        kukuk@suse.de
SuSE Linux AG        Deutschherrenstr. 15-19       D-90429 Nuernberg
--------------------------------------------------------------------    
Key fingerprint = A368 676B 5E1B 3E46 CFCE  2D97 F8FD 4E23 56C6 FB4B

Re: Illegal instruction on sparc32-linux

[David S. Miller]

   From: Thorsten Kukuk <kukuk@suse.de>
   Date: Fri, 19 Apr 2002 11:47:22 +0200

   On Thu, Apr 18, David S. Miller wrote:
   
   > Can you put the program under GDB so we can see what the instruction
   > is that it is trapping on?
   
   I tried it. But when I compile it with -g, I cannot reproduce it from
   the shell or from gdb. But if I call "make", it fails again.
    
It has to be dropping a core file somewhere, check that out
with gdb.

Re: Illegal instruction on sparc32-linux

[Thorsten Kukuk]

On Fri, Apr 19, David S. Miller wrote:

>    From: Thorsten Kukuk <kukuk@suse.de>
>    Date: Fri, 19 Apr 2002 11:47:22 +0200
> 
>    On Thu, Apr 18, David S. Miller wrote:
>    
>    > Can you put the program under GDB so we can see what the instruction
>    > is that it is trapping on?
>    
>    I tried it. But when I compile it with -g, I cannot reproduce it from
>    the shell or from gdb. But if I call "make", it fails again.
>     
> It has to be dropping a core file somewhere, check that out
> with gdb.

Ok, here are the results:

Core was generated by `troff -U -ms -mwww -Tps'.
Program terminated with signal 4, Illegal instruction.
Couldn't read input and local registers from core file
Reading symbols from /usr/lib/libstdc++.so.4...done.
Loaded symbols for /usr/lib/libstdc++.so.4
Reading symbols from /lib/libm.so.6...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /lib/libgcc_s.so.1...done.
Loaded symbols for /lib/libgcc_s.so.1
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Couldn't read input and local registers from core file
#0  0x00042ddc in diversion::need(vunits) ()
(gdb) x/i $pc
0x42ddc <_ZN9diversion4needE6vunits+28>:        call  %o1
(gdb) disass 
Dump of assembler code for function _ZN9diversion4needE6vunits:
0x42dc0 <_ZN9diversion4needE6vunits>:   save  %sp, -112, %sp
0x42dc4 <_ZN9diversion4needE6vunits+4>: add  %fp, -12, %l0
0x42dc8 <_ZN9diversion4needE6vunits+8>: mov  %i0, %o0
0x42dcc <_ZN9diversion4needE6vunits+12>:        ld  [ %i0 ], %o2
0x42dd0 <_ZN9diversion4needE6vunits+16>:        st  %l0, [ %sp + 0x40 ]
0x42dd4 <_ZN9diversion4needE6vunits+20>:        ld  [ %o2 + 0x18 ], %o1
0x42dd8 <_ZN9diversion4needE6vunits+24>:        ld  [ %i1 ], %i1
0x42ddc <_ZN9diversion4needE6vunits+28>:        call  %o1
0x42de0 <_ZN9diversion4needE6vunits+32>:        nop 
0x42de4 <_ZN9diversion4needE6vunits+36>:        unimp  0x4
0x42de8 <_ZN9diversion4needE6vunits+40>:        mov  %i0, %o0
0x42dec <_ZN9diversion4needE6vunits+44>:        mov  %l0, %o1
0x42df0 <_ZN9diversion4needE6vunits+48>:        ld  [ %fp + -12 ], %l1
0x42df4 <_ZN9diversion4needE6vunits+52>:        mov  1, %o3
0x42df8 <_ZN9diversion4needE6vunits+56>:        cmp  %l1, %i1

This is with binutils-2.12.90.0.4-3 (based on cvs from 8. April 2002),
gcc-3.1-20020415 and current glibc 2.2 branch.

  Thorsten

-- 
Thorsten Kukuk       http://www.suse.de/~kukuk/        kukuk@suse.de
SuSE Linux AG        Deutschherrenstr. 15-19       D-90429 Nuernberg
--------------------------------------------------------------------    
Key fingerprint = A368 676B 5E1B 3E46 CFCE  2D97 F8FD 4E23 56C6 FB4B

Re: Illegal instruction on sparc32-linux

[David S. Miller]

   From: Thorsten Kukuk <kukuk@suse.de>
   Date: Fri, 19 Apr 2002 13:10:12 +0200

   Couldn't read input and local registers from core file
   #0  0x00042ddc in diversion::need(vunits) ()
   (gdb) x/i $pc
   0x42ddc <_ZN9diversion4needE6vunits+28>:        call  %o1
   (gdb) disass 

Now.... print the value of the register $o1 so we can see
why it gets the illegal instruction...

Re: Illegal instruction on sparc32-linux

[Thorsten Kukuk]

On Fri, Apr 19, David S. Miller wrote:

>    From: Thorsten Kukuk <kukuk@suse.de>
>    Date: Fri, 19 Apr 2002 13:10:12 +0200
> 
>    Couldn't read input and local registers from core file
>    #0  0x00042ddc in diversion::need(vunits) ()
>    (gdb) x/i $pc
>    0x42ddc <_ZN9diversion4needE6vunits+28>:        call  %o1
>    (gdb) disass 
> 
> Now.... print the value of the register $o1 so we can see
> why it gets the illegal instruction...

(gdb) print $o1
$3 = 491224
(gdb) x/i $o1
0x77ed8 <ascii8>:       unimp  0x6aec8


-- 
Thorsten Kukuk       http://www.suse.de/~kukuk/        kukuk@suse.de
SuSE Linux AG        Deutschherrenstr. 15-19       D-90429 Nuernberg
--------------------------------------------------------------------    
Key fingerprint = A368 676B 5E1B 3E46 CFCE  2D97 F8FD 4E23 56C6 FB4B

Re: Illegal instruction on sparc32-linux

[David S. Miller]

Thorston, I believe we have discovered the cause of the
problems.  After I run some testsuites to check for regressions
I will update the GNATs entry for this bug and post the patch.

I will add you to the CC: of the GNATs PR so that you will know
when 3.1 CVS has the fix installed.

It turns out to be a generic sparc backend bug.