On Sun, Dec 18, 2005 at 06:56:34PM +0100, Aurelien Jarno wrote:
...
> It would be nice if somebody fluent with hppa assembly can tell us if 
> 
>       fldw -10(,sp),fr23
> 
> is a valid instruction or not.

Aurelien,
gdb may not be decoding the instruction correctly.
Shouldn't the target of "word" load be  "fr23L" or "fr23R"?

But "info float" shows "fr23" and "fr23R" - both 32-bit values:
fr23           1.74999988       (raw 0x3fdfffff)
fr23R          -nan(0x30a780)   (raw 0xffb0a780)

I was expecting "fr23" to be a 64-bit value (always).

Anyway something *is* causing the SIGILL in dmesg:
arch/parisc/math-emu/decode_exc.c(351) Unknown FPU exception 0x30

decode_fpu() prints the output and returns SIGILL:
        switch(Excp_type(exception_index)) {
...
        default:
                update_trap_counts(Fpu_register, aflags, bflags, trap_counts);
                printk("%s(%d) Unknown FPU exception 0x%x\n", __FILE__,
                        __LINE__, Excp_type(exception_index));
                return SIGNALCODE(SIGILL, ILL_COPROC);
...
        }

0x30 is "Invalid Exception".

PA20 arch book (page 8-6 and -7) describes a single precision
floating point with "E > 127" to indicate it's "NaN" (Not a Number).
The tail end of NaN handling on Page 8-24 clearly says "load and
store, ... are not arithmetic and do not signal an invalid operation
exception."

Page 10-10 describes causes of Invalid Exceptions and I don't see
how "fldw" could be any of them.

Using "cppunit-1.10.2" build:

grundler <166>/usr/share/qt3/bin/uic testbrowserdlg.ui -o testbrowserdlg.h
Illegal instruction
grundler <167>gdb /usr/share/qt3/bin/uic
GNU gdb 6.3-debian
...
(gdb) run testbrowserdlg.ui -o testbrowserdlg.h
Starting program: /usr/share/qt3/bin/uic testbrowserdlg.ui -o testbrowserdlg.h
(no debugging symbols found)
...
Program received signal SIGILL, Illegal instruction.
[Switching to Thread 16384 (LWP 10267)]
0x41aef534 in __umoddi3 () from /lib/libgcc_s.so.2
(gdb) x/20i 0x41aef500 
0x41aef500 <__umoddi3+1584>:    depw,z r25,%sar,32,r22
0x41aef504 <__umoddi3+1588>:    depw,z r24,%sar,32,r4
0x41aef508 <__umoddi3+1592>:    mtsar r21
0x41aef50c <__umoddi3+1596>:    shrpw r0,r26,%sar,r21
0x41aef510 <__umoddi3+1600>:    or r22,r21,r3
0x41aef514 <__umoddi3+1604>:    extrw,u r4,31,16,r21
0x41aef518 <__umoddi3+1608>:    stw r21,-10(,sp)
0x41aef51c <__umoddi3+1612>:    mtsar r20
0x41aef520 <__umoddi3+1616>:    extrw,u r4,15,16,r22
0x41aef524 <__umoddi3+1620>:    depw,z r26,%sar,32,r5
0x41aef528 <__umoddi3+1624>:    copy r22,r25
0x41aef52c <__umoddi3+1628>:    copy r3,r26
0x41aef530 <__umoddi3+1632>:    b,l 0x41ae9fd0 <__pthread_handles+2076304>,r31
0x41aef534 <__umoddi3+1636>:    fldw -10(,sp),fr23
0x41aef538 <__umoddi3+1640>:    stw ret1,-10(,sp)
0x41aef53c <__umoddi3+1644>:    fldw -10(,sp),fr24
0x41aef540 <__umoddi3+1648>:    xmpyu fr23,fr24,fr22
0x41aef544 <__umoddi3+1652>:    copy r3,r26
0x41aef548 <__umoddi3+1656>:    fstw fr22R,-10(,sp)
0x41aef54c <__umoddi3+1660>:    ldw -10(,sp),ret0

The offending fldw is in the branch delay slot when
calling __pthread_handles(). 
Are we allowed to put FP ops in the branch delay slot?

I don't know if this could be hiding a different problem.


[ New problem:
(gdb) bt
#0  0x41aef534 in __umoddi3 () from /lib/libgcc_s.so.2
#1  0x00000008 in ?? ()
Cannot find bounds of current function (@0x0), unwinding will fail.
(gdb) 
]


FWIW, I can reproduce the problem using gcc-3.4 and g++-3.4:
(I also get the "Unknown FPU exception 0x30" in dmesg output.)
        cd /usr/src/qt-x11-free-3.3.5/
        make clean
        make CXX=g++-3.4 CC=gcc-3.4
...
/usr/src/qt-x11-free-3.3.5/bin/uic -L /usr/src/qt-x11-free-3.3.5/plugins 
pixmapfunction.ui -o pixmapfunction.h
make[4]: *** [pixmapfunction.h] Illegal instruction
make[4]: *** Deleting file `pixmapfunction.h'
make[4]: Leaving directory `/usr/src/qt-x11-free-3.3.5/tools/designer/designer'


hth,
grant


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to