Tak mnie dziwiło dlaczego liboil się wykłada przy teście obsługi altivec, zgłaszając SIGSEGV zamiast ew. SIGILL (choć anduril to IIRC G4 i powinien altivec mieć[1]) i kończąc program pomimo uruchomionego gdb... aż napisałem dmesg i wszystko stało się jasne:
Oops: kernel access of bad area, sig: 11 [#9] NIP: C0008B84 LR: C0007F2C SP: CE09BF20 REGS: ce09be70 TRAP: 0300 Not tainted MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11 DAR: 00000084, DSISR: 40000000 TASK = cc8b9220[23279] 'lt-build_protot' THREAD: ce09a000Last syscall: 173 GPR00: C0007F2C CE09BF20 CC8B9220 00000000 00000000 00030001 0FF97DF4 0FDD1CF4 GPR08: 0000D032 C0007F2C 00009032 C0350000 0C8B94B8 10018CEC 10410000 10090000 GPR16: 00000000 00000000 00000000 1009E6C0 1009E578 00000000 10070000 00000001 GPR24: 10000600 7FFFF0A8 100007AC 0FED964C 00000001 7FFFF004 0FFED798 00000000 Call trace: [c0007f2c] (tego jest już 9 sztuk) $ uname -a Linux anduril 2.6.8 #1 Tue Oct 19 18:04:24 UTC 2004 ppc unknown unknown PLD Linux 173 to sys_rt_sigaction. c0007f2c to początek ret_from_except(). c0008b84 jest w AltivecUnavailException() Wygląda na to, że AltivecUnavailException jest wywoływane z NULLem jako parametrem. [1] i co z tego, jak w dystrybucyjnym 2.6 obsługa altiveca jest wyłączona. Dlaczego??? Żeby zniechęcić użytkowników *Maców do PLD (albo odwrotnie)? W 2.4 jest włączona. -- Jakub Bogusz http://cyber.cs.net.pl/~qboosh/ _______________________________________________ pld-devel-pl mailing list [email protected] http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
