Hi Matthew, several PCRE2 improvements were migrated to PCRE in 8.39. That might be the cause of the issue. However from the report it is difficult to tell what is happening.
>Program received signal SIGILL, Illegal instruction. >0xb7faf0ec in ?? () >=> 0xb7faf0ec: li r3,-1 load immediate is a basic instruction. >=> 0xb7fe5008: mflr r0 This is the way to return from a function call. >=> 0xb7faf060: lwz r28,8(r5) Load word also a basic instruction. Is it possible that the SIGILL is imprecise and the previous instruction is the invalid one? E.g: disassemble addr-16,addr+16 Or perhaps execution rights are not enabled for that instruction? 008, 060 is somewhere at the beginning of a 4K page, perhaps the page has invalid rights (or some security enhancement disallow RWX)? Regards, Zoltan Matthew Vernon <matt...@debian.org> írta: >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.a...@manchmal.in-ulm.de> >Resent-To: debian-bugs-d...@lists.debian.org >Resent-CC: Matthew Vernon <matt...@debian.org> >Date: Mon, 10 Oct 2016 22:37:40 +0200 >From: Christoph Biedl <debian.a...@manchmal.in-ulm.de> >Reply-To: Christoph Biedl <debian.a...@manchmal.in-ulm.de>, >840...@bugs.debian.org >To: Debian Bug Tracking System <sub...@bugs.debian.org> > >Package: src:pcre3 >Version: 2:8.39-2 >Severity: important >Usertag: debian-powe...@lists.debian.org > >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 > > > >-- >## List details at https://lists.exim.org/mailman/listinfo/pcre-dev -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
