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 

Reply via email to