Hi,
I've had the following bug report submitted; if the submitter is correct
(which seems likely, but I don't have a G4 powerpc box to test on), then
the jit code in 8.39 is using G5 instructions inappropriately (where the
8.38 code didn't).
Obviously, I could just disable jit for this architecture, but I'd
rather avoid it if possible...
Regards,
Matthew
-------- Forwarded Message --------
Subject: Bug#840354: src:pcre3: FTBFS on powerpc (G4 CPU)
Resent-Date: Mon, 10 Oct 2016 20:39:06 +0000
Resent-From: Christoph Biedl <debian.axhn@???>
Resent-To: debian-bugs-dist@???
Resent-CC: Matthew Vernon <matthew@???>
Date: Mon, 10 Oct 2016 22:37:40 +0200
From: Christoph Biedl <debian.axhn@???>
Reply-To: Christoph Biedl <debian.axhn@???>,
840354@???
To: Debian Bug Tracking System <submit@???>
Package: src:pcre3
Version: 2:8.39-2
Severity: important
Usertag: debian-powerpc@???
Dear Maintainer,
Rebuilding syslog-ng 3.7.3-3 on a PowerMac G4 failed with SIGILL,
debugging led to libpcre, and finally rebuilding src:pcre3 itself
fails with very similar symptoms:
(...)
/usr/bin/make check-TESTS
make[3]: Entering directory '/tmp/pcre3/pcre3-8.39'
make[4]: Entering directory '/tmp/pcre3/pcre3-8.39'
./test-driver: line 107: 12195 Illegal instruction "$@" > $log_file 2>&1
FAIL: pcre_jit_test
PASS: pcrecpp_unittest
PASS: pcre_scanner_unittest
(...)
The failing program is .libs/lt-pcre_jit_test. Using gdb is no help at
all, the failures happen at a different point every invocation:
Program received signal SIGILL, Illegal instruction.
0xb7faf0ec in ?? ()
(gdb) bt
#0 0xb7faf0ec in ?? ()
#1 0x1ff30718 in ?? ()
#2 0x1ff30718 in ?? ()
#3 0x1ff0adf4 in ?? ()
#4 0x200061c8 in ?? ()
#5 0x20004a3c in ?? ()
#6 0x1fc97274 in ?? ()
#7 0x1fc9747c in ?? ()
#8 0x00000000 in ?? ()
(gdb) disassemble 0xb7faf0ec,0xb7faf0ff
Dump of assembler code from 0xb7faf0ec to 0xb7faf0ff:
=> 0xb7faf0ec: li r3,-1
0xb7faf0f0: addi r5,r30,6
0xb7faf0f4: cmplw cr1,r5,r29
0xb7faf0f8: bgt cr1,0xb7faf1b8
0xb7faf0fc: lwz r5,36(r1)
Program received signal SIGILL, Illegal instruction.
0xb7fe5008 in ?? ()
(gdb) bt
#0 0xb7fe5008 in ?? ()
#1 0x1ffb8b80 in ?? ()
#2 0x1ff91820 in ?? ()
#3 0x20006110 in ?? ()
#4 0x20004a3c in ?? ()
#5 0x1fc97274 in ?? ()
#6 0x1fc9747c in ?? ()
#7 0x00000000 in ?? ()
(gdb) disassemble 0xb7fe5008,0xb7fe5020
Dump of assembler code from 0xb7fe5008 to 0xb7fe5020:
=> 0xb7fe5008: mflr r0
0xb7fe500c: stw r31,-4(r1)
0xb7fe5010: stw r30,-8(r1)
0xb7fe5014: stw r29,-12(r1)
0xb7fe5018: stw r28,-16(r1)
0xb7fe501c: stw r27,-20(r1)
Program received signal SIGILL, Illegal instruction.
0xb7faf060 in ?? ()
(gdb) bt
#0 0xb7faf060 in ?? ()
#1 0x1ff30718 in ?? ()
#2 0x1ff30718 in ?? ()
#3 0x1ff0adf4 in ?? ()
#4 0x200061c8 in ?? ()
#5 0x20004a3c in ?? ()
#6 0x1fc97274 in ?? ()
#7 0x1fc9747c in ?? ()
#8 0x00000000 in ?? ()
(gdb) disassemble 0xb7faf060,0xb7faf070
Dump of assembler code from 0xb7faf060 to 0xb7faf070:
=> 0xb7faf060: lwz r28,8(r5)
0xb7faf064: addi r3,r3,1
0xb7faf068: stw r3,32(r1)
0xb7faf06c: b 0xb7faf0cc
My last rebuild of syslog-ng in July, using pcre3 version 2:8.38-3.1,
succeded. Therefore I guess it's the changes between 8.38 and 8.39.
Very likely this was introduced by the changes in the ppc_jit code
which unfortunately I was unable to understand.
Disabling jit for powerpc using the following patch:
--- pcre3-8.39.orig/sljit/sljitConfigInternal.h
+++ pcre3-8.39/sljit/sljitConfigInternal.h
@@ -135,11 +135,7 @@
#elif defined(__ppc64__) || defined(__powerpc64__) ||
defined(_ARCH_PPC64) || (defined(_POWER) && defined(__64BIT__))
#define SLJIT_CONFIG_PPC_64 1
#elif defined(__ppc__) || defined(__powerpc__) || defined(_ARCH_PPC) ||
defined(_ARCH_PWR) || defined(_ARCH_PWR2) || defined(_POWER)
-# ifndef __NO_FPRS__
-# define SLJIT_CONFIG_PPC_32 1
-# else
# define SLJIT_CONFIG_UNSUPPORTED 1
-# endif
#elif defined(__mips__) && !defined(_LP64)
#define SLJIT_CONFIG_MIPS_32 1
#elif defined(__mips64)
resulted in a successful pcre3 build, and using the created packages
also syslog-ng passes the failing test again.
So I'm asking you to bring this upstream to sort out how the breakage
was introduced. From other bug reports I guess the created code uses
G5 instructions; the Debian powerpc buildds didn't notice as they
actually are such newer boxes.
As a hopefully temporary workaround you could disable jit for powerpc,
of course a the cost of a performance penalty.
Christoph
-- System Information:
Debian Release: stretch/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: powerpc (ppc)
Kernel: Linux 4.4.23
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect
