Bug#341675: qt-x11-free build fails
Grant, thank you for your work to date on this bug. (BTW, it would be helpful if you would follow up to bug #342545 on libgcc2, instead of bug #341675 which is filed against just one of the many packages affected by it). Unfortunately, it doesn't seem from the bug log as though much progress is being made towards a resolution. At this point, the KDE transition has been completed in testing for all architectures, with the exception of hppa as a result of this bug. The release team is already moving on to other transitions that need to happen for etch, including another round of dbus-related KDE changes. This is a release-critical bug, and it is impacting hppa's ability to keep up with etch at large, extending even to such core packages as aptitude (build-depends on cppunit; now uninstallable in testing on hppa). Is there progress being made on this bug that's not shown in the bug log, or do we need to consider dropping hppa from the list of etch release archs at this point? Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#341675: qt-x11-free build fails
On Sat, Jan 07, 2006 at 01:05:11AM -0800, Steve Langasek wrote: Grant, thank you for your work to date on this bug. (BTW, it would be helpful if you would follow up to bug #342545 on libgcc2, instead of bug #341675 which is filed against just one of the many packages affected by it). Steve, welcome! I'm just replying to what was already on the CC list. I've also added parisc-linux mailing list since this may involve kernel and/or need FP unit expertise that I don't have. Unfortunately, it doesn't seem from the bug log as though much progress is being made towards a resolution. We (several hppa developers) are working on it. But keep in mind this is a hobby for all of us. At this point, the KDE transition has been completed in testing for all architectures, with the exception of hppa as a result of this bug. The release team is already moving on to other transitions that need to happen for etch, including another round of dbus-related KDE changes. My opinion: release team should move on and ignore hppa until this is resolved. If it doesn't get resolved in the next couple of weeks (say by Feb or mid-Feb), then drop hppa from etch. But I'm not a DD and don't want to know the politics involved. Just my $0.02. This is a release-critical bug, and it is impacting hppa's ability to keep up with etch at large, extending even to such core packages as aptitude (build-depends on cppunit; now uninstallable in testing on hppa). *nod* - I saw the KDE dependency already. Is there progress being made on this bug that's not shown in the bug log, or do we need to consider dropping hppa from the list of etch release archs at this point? Yes, we are making progress - nothing new to report since last week. I'm looking at it today and will consult with other hppa developers once I have more data later today. And as noted above, I think release team should informally ignore hppa until this is resolved and we catch up again. But I don't know what the politics or policys in Debian allow for. I'm just a (mostly) happy debian user and upstream (hppa) maintainer. thanks, grant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341675: qt-x11-free build fails
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.7488 (raw 0x3fdf)
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 167gdb /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 0x0008 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]
Bug#341675: qt-x11-free build fails
On Wed, Dec 28, 2005 at 02:04:44AM -0500, Steve M. Robbins wrote: Rather than debugging this by remote control, you might find it easier to simply run uic yourself. Obtain the sources for cppunit (e.g. by apt-get source cppunit) then do: cd src/qttestrunner /usr/share/qt3/bin/uic testbrowserdlg.ui -o testbrowserdlg.h (per http://buildd.debian.org/fetch.php?pkg=cppunitver=1.10.2-5arch=hppastamp=1134615988file=logas=raw) Yup - thanks. I'm able to reproduce the illegal instruction symptom with both qt-x11-free-3.3.5 and cppunit-1.10.2 . I have no clue what the problem but find it odd that uic is the only program to expose it. I've tried and reproduced the problem with testing and sid releases (systems riot and ios respectively). I'll look at it some more and see if I can get some help. thanks, grant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341675: qt-x11-free build fails
Dear Grant, On Sun, Dec 25, 2005 at 12:27:59AM -0700, Grant Grundler wrote: Can you provide more context around the offending insn? 10 lines of asm before and after the SIGILL instruction? And possibly a register dump just before the SIGILL is issued? It would be interesting to know what %SP is. Rather than debugging this by remote control, you might find it easier to simply run uic yourself. Obtain the sources for cppunit (e.g. by apt-get source cppunit) then do: cd src/qttestrunner /usr/share/qt3/bin/uic testbrowserdlg.ui -o testbrowserdlg.h (per http://buildd.debian.org/fetch.php?pkg=cppunitver=1.10.2-5arch=hppastamp=1134615988file=logas=raw) Regards, -Steve -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341675: qt-x11-free build fails
On Sun, Dec 18, 2005 at 06:56:34PM +0100, Aurelien Jarno wrote: ... and now the problem is a SIGILL that occurs a few instructions later when calling __umoddi3 from libgcc_s.so.2. ... 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, fldw is a valid instruction and is used frequently in libgcc_s.so.2: grundler 507objdump -rD /lib/libgcc_s.so.2 | fgrep fldw | fgrep fr23 | wc -l 36 But there's more than a few calls/branches to __umoddi3. grundler 504objdump -rD /lib/libgcc_s.so.2 | fgrep __umoddi3 | wc -l 43 Can you provide more context around the offending insn? 10 lines of asm before and after the SIGILL instruction? And possibly a register dump just before the SIGILL is issued? It would be interesting to know what %SP is. thanks, grant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341675: qt-x11-free build fails
reassign 341675 libgcc2 4.0.2-5 thanks On Sun, Dec 18, 2005 at 06:56:34PM +0100, Aurelien Jarno wrote: On Mon, Dec 12, 2005 at 02:41:49AM -0800, Steve Langasek wrote: This is a bug that was believed fixed previously, but it is *not* bug #326581; it's bug #333766, which was fixed in glibc 2.3.5-7. (And it really was fixed, otherwise kdelibs4c2 wouldn't be in testing right now for hppa.) But it's back in 2.3.5-8; could this have to do with the fact that 2.3.5-7 was built (wrongly) with gcc-4.0, and 2.3.5-8 is the first version to build with gcc-3.4? I confirm. Bug #333766 was causing a SIGBUS in uic, when calling feholdexcept. This has been fixed, and now the problem is a SIGILL that occurs a few instructions later when calling __umoddi3 from libgcc_s.so.2. I have tried other version of libgcc2, from version 4.0.1-7 to version 4.1-0exp4, and the problem is always there. So it does not seems related to a recent change in gcc. Maybe this part of code was never called before for some strange reasons. It would be nice if somebody fluent with hppa assembly can tell us if fldw -10(,sp),fr23 is a valid instruction or not. If not, that's probably a miscompilation in gcc, as this code is generated from C code. Ok; reassigning to libgcc2 then. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#341675: qt-x11-free build fails
On Mon, Dec 12, 2005 at 02:41:49AM -0800, Steve Langasek wrote: This is a bug that was believed fixed previously, but it is *not* bug #326581; it's bug #333766, which was fixed in glibc 2.3.5-7. (And it really was fixed, otherwise kdelibs4c2 wouldn't be in testing right now for hppa.) But it's back in 2.3.5-8; could this have to do with the fact that 2.3.5-7 was built (wrongly) with gcc-4.0, and 2.3.5-8 is the first version to build with gcc-3.4? I confirm. Bug #333766 was causing a SIGBUS in uic, when calling feholdexcept. This has been fixed, and now the problem is a SIGILL that occurs a few instructions later when calling __umoddi3 from libgcc_s.so.2. I have tried other version of libgcc2, from version 4.0.1-7 to version 4.1-0exp4, and the problem is always there. So it does not seems related to a recent change in gcc. Maybe this part of code was never called before for some strange reasons. It would be nice if somebody fluent with hppa assembly can tell us if fldw -10(,sp),fr23 is a valid instruction or not. If not, that's probably a miscompilation in gcc, as this code is generated from C code. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
