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 <matthew@???> í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.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
>
>
>
>--
>## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
