; compilation unit aborted ; caught 1 fatal ERROR condition make: *** [../asdf-module.mk:41: test] Error 1 make: Leaving directory '/var/tmp/portage/dev-lisp/sbcl-1.4.13/work/sbcl-1.4.13/contrib/sb-capstone' + exit 2 + for i in $contribs_to_build ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 17.0-desktop-gnome-systemd_libressl-test_20181217-071216 ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-7.3.1 [2] x86_64-pc-linux-gnu-8.2.0 * Available Python interpreters, in order of preference: [1] python3.7 [2] python3.6 [3] python2.7 (fallback) Available Ruby profiles: [1] ruby23 (with Rubygems) [2] ruby24 (with Rubygems) [3] ruby25 (with Rubygems) * java-config: The following VMs are available for generation-2: *) IcedTea JDK 3.9.0 [icedtea-bin-8] 2) JamVM JDK 2.0.0 [jamvm] Available Java Virtual Machines: [1] icedtea-bin-8 system-vm [2] jamvm emerge -qpvO dev-lisp/sbcl [ebuild N ] dev-lisp/sbcl-1.4.13 USE="threads unicode zlib -debug -doc -pax_kernel -source"
Created attachment 558292 [details] emerge-info.txt
Created attachment 558294 [details] dev-lisp:sbcl-1.4.13:20181221-025548.log
Created attachment 558296 [details] emerge-history.txt
Created attachment 558298 [details] environment
Created attachment 558300 [details] etc.portage.tbz2
Created attachment 558302 [details] temp.tbz2
I'm seeing this with sbcl-1.4.15, it's also failing on the test in capstone. Is it possible the test is wrong? Here's the relevant lisp code: (deftest ppc-little-endian (capstone-check '(#x03 #x10 #x40 #x3c #x00 #x81 #x42 #x38) '(:ppc64 :little-endian) '("LIS R2, 0X1003" "ADDI R2, R2, -0X7F00")) t) I'm not sure that this is a correct adaptation, but my quick check in python does not yield the result that the test expects, either. nlsielicki@fastdog ~ $ python3 Python 3.6.6 (default, Dec 28 2018, 19:58:16) [GCC 8.2.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> from capstone import * >>> CODE = b"\x03\x10\x40\x3c\x00\x81\x42\x38" >>> md = Cs(CS_ARCH_PPC, CS_MODE_LITTLE_ENDIAN) >>> for i in md.disasm(CODE, 0x1000): ... print("0x%x:\t%s\t%s" %(i.address, i.mnemonic, i.op_str)) ... 0x1000: lis r2, 0x1003 0x1004: addi r2, r2, 0x8100 It's an immediate value and you can see 0081 in the source clearly, not sure what to make of it.
This test has been changed in master https://sourceforge.net/p/sbcl/sbcl/ci/04a38c3d1ea141d3b9b346593f9b184878d1f869/
*** Bug 674322 has been marked as a duplicate of this bug. ***
(In reply to Nicholas Sielicki from comment #8) > This test has been changed in master > > https://sourceforge.net/p/sbcl/sbcl/ci/ > 04a38c3d1ea141d3b9b346593f9b184878d1f869/ Thanks for that pointer. I'll attach a patch which fixes this.
Created attachment 559586 [details, diff] patch which fixes the capstone test
Created attachment 559588 [details] ebuild which applies the capstone test fix
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f6fac3aeaad8c83b552f800ce75449962d31d524 commit f6fac3aeaad8c83b552f800ce75449962d31d524 Author: Andrey Grozin <grozin@gentoo.org> AuthorDate: 2019-01-03 15:42:45 +0000 Commit: Andrey Grozin <grozin@gentoo.org> CommitDate: 2019-01-03 15:43:57 +0000 dev-lisp/sbcl: fix the capstone test Suggested-by: Helmut Jarausch <jarausch@igpm.rwth-aachen.de> Closes: https://bugs.gentoo.org/673522 Signed-off-by: Andrey Grozin <grozin@gentoo.org> Package-Manager: Portage-2.3.41, Repoman-2.3.9 dev-lisp/sbcl/files/sbcl-1.4.15-capstone.patch | 15 +++++++++++++++ dev-lisp/sbcl/sbcl-1.4.15.ebuild | 1 + 2 files changed, 16 insertions(+)
Just for reference's sake, the test broke because capstone 4.0 released about a week before Christmas. From the changelog: https://www.capstone-engine.org/Version-4.0-changelog > PowerPC: > * Change cs_ppc_op.imm type from int32_t to int64_t. The type on immediate operands was changed, so the number that used to be parsed as two's complement due to a MSB of 1 suddenly was being read as positive due to the extra padding. 8100 -> 2#1000000100000000 in 16 bits 8100 -> 2#00000000000000001000000100000000 in 32 bits. That doesn't really make sense though, because it changed from 32_t to 64_t, not 16_t to 32_t. I don't know what I'm missing but all is well that ends well. Thank you for the patch and update.
*** Bug 674428 has been marked as a duplicate of this bug. ***
*** Bug 693208 has been marked as a duplicate of this bug. ***
