SIGILL on Sparc

Piotr Wyderski piotr.wyderski@gmail.com
Tue Oct 6 09:28:00 GMT 2009


Hello,

I have a problem with a (big) C++ program compiled
with gcc 4.4.0 on a 64-bit Sparc.

Target: sparc-sun-solaris2.10

Configured with: /opt/sources/gnu/gcc-4.4.0/configure
--prefix=/opt/gnu/gcc-4.4.0 --with-local-prefix=/opt/gnu/gcc-4.4.0
--enable-threads=posix --with-cpu=ultrasparc3 --enable-tls=yes
--with-tune=ultrasparc3 --enable-languages=c,c++ --with-as=/usr/ccs/bin/as
--with-ld=/usr/ccs/bin/ld --with-gmp=/opt/gnu/gmp-4.2.1
--with-mpfr=/opt/gnu/mpfr-2.4.1 --disable-nls

Thread model: posix

gcc version 4.4.0 (GCC)

The compiler generated the following code (debug version):

0xffffffff751407b4 <Functions+204>:     nop
0xffffffff751407b8 <Functions+208>:     ldx  [ %fp + 0x87f ], %o0
0xffffffff751407bc <Functions+212>:     clr  %o1
0xffffffff751407c0 <Functions+216>:     call  0xffffffff7543bc00
<_ZN6parser8internal9Functions11setCategoryENS0_11EH_CategoryE@plt>
0xffffffff751407c4 <Functions+220>:     nop
0xffffffff751407c8 <Functions+224>:     ta  5 <=== Here the SIGILL happens

The function SetCategory(v) returns void and simply assigns
the value of v to a class member, so there are no trap conditions.
TA, on the other hand, stands for "trap always", so the condition
code is unimportant anyway. Why has the trap instruction been generated?

Best regards
Piotr Wyderski



More information about the Gcc mailing list