On Tue, Feb 22, 2022 at 11:58:49PM -0500, George Koehler wrote:
> On Wed, 23 Feb 2022 00:08:34 +0100
> Omar Polo <o...@openbsd.org> wrote:
>
> > I think I've finally solved it. The problem is that contrib/sb-capstone
> > hardcodes some values from capstone.h so lisp can call the C functions.
> > This "transcription" however is not accurate and worked until now by
> > pure chance on 64 bit arches due to how arguments are passed and struct
> > padding, pure luck!
>
> I tried to patch capstone.lisp but didn't fix my build. Your patch
> looks better, but I haven't built it. I have comments below.
>
> The build deletes every *.orig and breaks "make update-patches", so
> I started using "PATCHORIG= .orig.port". Joshua Elsasser, as the
> maintainer, do you have an opinion about PATCHORIG?
I will try to find some time to take a look at it this week. For what
it's worth, 32-bit powerpc is usually a bit broken on non-openbsd
platforms as well. I have a couple g4 mac minis that I can test on,
assuming they haven't died.
Switching to ECL as the cross-build host is something what we probably
want to do, as it would also allow sbcl to be build on arm and
arm64. I had a version of the port which did this but as you saw, it
was rather slower than with clisp.
> Go down for patch comments.
>
> > Index: Makefile
> > ===================================================================
> > RCS file: /cvs/ports/lang/sbcl/Makefile,v
> > retrieving revision 1.47
> > diff -u -p -r1.47 Makefile
> > --- Makefile 31 Dec 2021 09:53:11 -0000 1.47
> > +++ Makefile 22 Feb 2022 23:07:25 -0000
> > @@ -1,31 +1,12 @@
> > # $OpenBSD: Makefile,v 1.47 2021/12/31 09:53:11 solene Exp $
> >
> > -BROKEN-i386 = build fails in "Compiling file
> > [...]/src/compiler/generic/genesis.lisp"
> > -# ;; Compiling file
> > /pobj/sbcl-2.0.1/sbcl-2.0.1/src/compiler/generic/genesis.lisp ...
> > -# ;; Wrote file
> > /pobj/sbcl-2.0.1/sbcl-2.0.1/obj/from-host/src/compiler/generic/genesis.fas-tmp
> > -# 0 errors, 0 warnings
> > -# ;; Loading file obj/from-host/src/compiler/generic/genesis.fas ...
> > -# ;; Loaded file obj/from-host/src/compiler/generic/genesis.fas
> > -# *** - OPEN: File
> > -# #P"/pobj/sbcl-2.0.1/sbcl-2.0.1/obj/from-xc/tls-init.lisp-expr"
> > does not
> > -# exist
> > -# The following restarts are available:
> > -# SKIP :R1 skip (GENESIS OBJECT-FILE-NAMES # ...)
> > -# RETRY :R2 retry (GENESIS OBJECT-FILE-NAMES # ...)
> > -# STOP :R3 stop loading file
> > /pobj/sbcl-2.0.1/sbcl-2.0.1/make-genesis-2.lisp
> > -# ABORT-BUILD :R4 Abort building SBCL.
> > -# ABORT :R5 Abort main loop
> > -# //testing for consistency of first and second GENESIS passes
> > -# diff: output/genesis-2: No such file or directory
> > -# error: header files do not match between first and second GENESIS
> > -
> > # not yet ported to other arches
> > ONLY_FOR_ARCHS = amd64 i386 powerpc
> > USE_WXNEEDED = Yes
> >
> > COMMENT= compiler and runtime system for ANSI Common Lisp
> >
> > -V = 2.1.11
> > +V = 2.2.1
> > DISTNAME= sbcl-${V}-source
> > PKGNAME= sbcl-${V}
> > WRKDIST= ${WRKDIR}/sbcl-${V}
> > @@ -58,10 +39,17 @@ WANTLIB+= pthread
> > MAKE_PARAMS += --with-sb-core-compression \
> > --with-sb-xref-for-internals
> >
> > +# contrib/sb-capstone/test.lisp opens it at build-time if present
> > +BUILD_DEPENDS = devel/capstone/main
> > +
> > .if ${FLAVOR:Mnative_bootstrap}
> > BUILD_DEPENDS+= lang/sbcl
> > BOOTSTRAP_CMD= ${LOCALBASE}/bin/sbcl \
> > --disable-debugger --no-sysinit --no-userinit
> > +.elif ${MACHINE_ARCH:Mi386}
> > +# ecl is way slower but clips fails to build sbcl on i386
> > +BUILD_DEPENDS += lang/ecl
> > +BOOTSTRAP_CMD = ${LOCALBASE}/bin/ecl -q --norc
> > .else
> > BUILD_DEPENDS += lang/clisp
> > BOOTSTRAP_CMD = ${LOCALBASE}/bin/clisp -q -norc
> > Index: distinfo
> > ===================================================================
> > RCS file: /cvs/ports/lang/sbcl/distinfo,v
> > retrieving revision 1.21
> > diff -u -p -r1.21 distinfo
> > --- distinfo 31 Dec 2021 09:53:11 -0000 1.21
> > +++ distinfo 22 Feb 2022 23:07:25 -0000
> > @@ -1,2 +1,2 @@
> > -SHA256 (sbcl-2.1.11-source.tar.bz2) =
> > v8FIHef9vfru8qsPDo6E79NDQz3qjSHPvqiwFGy9/v0=
> > -SIZE (sbcl-2.1.11-source.tar.bz2) = 6687529
> > +SHA256 (sbcl-2.2.1-source.tar.bz2) =
> > Xdbm4/CLfG7fJioOhEqfi15WLMoIFVA0wfLAFPyQh9o=
> > +SIZE (sbcl-2.2.1-source.tar.bz2) = 6701705
> > Index: patches/patch-contrib_sb-capstone_capstone_lisp
> > ===================================================================
> > RCS file: patches/patch-contrib_sb-capstone_capstone_lisp
> > diff -N patches/patch-contrib_sb-capstone_capstone_lisp
> > --- /dev/null 1 Jan 1970 00:00:00 -0000
> > +++ patches/patch-contrib_sb-capstone_capstone_lisp 22 Feb 2022 23:07:25
> > -0000
> > @@ -0,0 +1,26 @@
> > +$OpenBSD$
> > +
> > +sync a couple of size mismatches with capstone.h; fixes the build on
> > +32bit arches (i386, powerpc.)
> > +
> > +Index: contrib/sb-capstone/capstone.lisp
> > +--- contrib/sb-capstone/capstone.lisp.orig
> > ++++ contrib/sb-capstone/capstone.lisp
> > +@@ -285,7 +285,7 @@
> > + (define-alien-type cs-insn
> > + (struct nil
> > + (insn-id int)
> > +- (insn-addr unsigned)
> > ++ (insn-addr (integer 64))
> > + (insn-size short)
> > + (insn-bytes (array char 16))
> > + (insn-mnemonic (array char 32))
>
> I guess that it should be (insn-addr (unsigned 64)), to match the
> capstone.h's struct cs_insn's uint64_t address.
>
> I have not called C from Lisp before now, so sb-alien confused me.
> I now believe that "integer" and "unsigned" have pointer size, but
> "int" and "unsigned-int" have 32 bits. So "unsigned" had 64 bits
> on amd64, or 32 bits on i386|powerpc.
>
> > +@@ -310,7 +310,7 @@
> > +
> > + ;; The handle returned by cs-open will be represented as being of type
> > unsigned
> > +
> > +-(define-alien-routine cs-open int (arch int) (mode (integer 64)) (handle
> > unsigned :out))
> > ++(define-alien-routine cs-open int (arch int) (mode unsigned) (handle
> > unsigned :out))
> > +
> > + (define-alien-routine cs-version unsigned (major int :out) (minor int
> > :out))
> > +
>
> cs-open should have "(mode int)". <capstone.h> has "cs_mode mode" and
> powerpc clang says that "(cs_mode)-1 > 0" is false, implying that
> cs_mode is a signed type.
>
> I also think that cs-version should return "unsigned-int" (32 bits),
> not "unsigned" (64 bits on amd64), though I suspect that amd64
> tolerates the wrong size.
>
> --George
