Can we try and fix this properly? I'm always loathe to discard fast features just because. I'd rather understand the crash better. Tim?

Hi,

In response to Marcel - it does not seem that these fast code paths are designed to work on x86.

This is selected in ./opensmalltalk-vm/platforms/unix/config/configure around line 18555 or so. I have pasted it below.

The BitBltGeneric.c file that fails is only but for Arm32 and Arm64.

In the x86-64 one only uses BitBltPlugin.c.

I've not spent a lot of time looking but it looks like the contents of platforms/Cross/plugins/BitBltPlugin is just the source code that the Pi Foundation paid to write.

So now it is clearer why it never failed for anything else other than the ArmV8 systems.

Maybe the other problem is that accidentally this is thinking it is still on a 32 bit systems rather than a 64 bit systems since it does seem to be used by the 32 bit systems as well.

When I set a breakpoint at fastPathBottomToTop on a Arm32 system, and then do the steps above that causes the crash on Arm64 then it hits the breakpoint.

cheers

bruce

Arm32 example:

$ lscpu Architecture: armv7l Byte Order: Little Endian CPU(s): 4 On-line CPU(s) list: 0-3 Thread(s) per core: 1 Core(s) per socket: 4 Socket(s): 1 Vendor ID: ARM Model: 3 Model name: Cortex-A72 Stepping: r0p3 CPU max MHz: 1800.0000 CPU min MHz: 600.0000 BogoMIPS: 108.00 Flags: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32

GNU gdb (Raspbian 8.2.1-2) 8.2.1 Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "arm-linux-gnueabihf". Type "show configuration" for configuration details. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/. Find the GDB manual and other documentation resources online at: http://www.gnu.org/software/gdb/documentation/.

For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from ./squeak...done. (gdb) break fastPathBottomToTop Breakpoint 1 at 0xc1b0c: file. XXXopensmalltalk-vm/platforms/Cross/plugins/BitBltPlugin/BitBltGeneric.c, line 519. (gdb) run ~/archive/StcStw/sim/StcStw-32 Starting program: XXX/local/squeak/squeak ~/archive/StcStw/sim/StcStw-32 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1". [New Thread 0xb5eaa400 (LWP 22687)] [New Thread 0xb56a9400 (LWP 22688)] [New Thread 0xb4da8400 (LWP 22689)] pthread_setschedparam failed: Operation not permitted This VM uses a separate heartbeat thread to update its internal clock and handle events. For best operation, this thread should run at a higher priority, however the VM was unable to change the priority. The effect is that heavily loaded systems may experience some latency issues. If this occurs, please create the appropriate configuration file in /etc/security/limits.d/ as shown below:

cat <<END | sudo tee /etc/security/limits.d/squeak.conf * hard rtprio 2 * soft rtprio 2 END

and report to the squeak mailing list whether this improves behaviour.

You will need to log out and log back in for the limits to take effect. For more information please see https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/r3732#linux

Thread 1 "squeak" hit Breakpoint 1, fastPathBottomToTop (op=0xbefcc7a8, flags=541212736)

Snip from configure.

plugin="BitBltPlugin" plibs="" rm -f BitBltPlugin.sub BitBltPlugin.lib bitblt_objs="BitBltPlugin.o" bitblt_flags="" arm_arch=""

case $host_cpu in arm*) case $host_cpu in armv6*) arm_arch="6" ;; armv7*) arm_arch="7-A" ;; esac # Check whether --enable-fast-bitblt was given. if test "${enable_fast_bitblt+set}" = set; then : enableval=$enable_fast_bitblt; if test "x$enableval" = "xyes" ; then bitblt_objs="BitBltPlugin.o BitBltArm.o BitBltArmLinux.o BitBltArmSimd.o BitBltDispatch.o BitBltGeneric.o BitBltArmSimdAlphaBlend.o BitBltArmSimdBitLogical.o BitBltArmSimdCompare.o BitBltArmSimdPixPaint.o BitBltArmSimdSourceWord.o" bitblt_flags="-DENABLE_FAST_BLT" fi

fi

;; aarch64) # Check whether --enable-fast-bitblt was given. if test "${enable_fast_bitblt+set}" = set; then : enableval=$enable_fast_bitblt; if test "x$enableval" = "xyes" ; then bitblt_objs="BitBltPlugin.o BitBltArm64.o BitBltDispatch.o BitBltGeneric.o" bitblt_flags="-DENABLE_FAST_BLT" fi

fi

;;

esac

BITBLT_OBJS=$bitblt_objs

BITBLT_FLAGS=$bitblt_flags

ARM_ARCH=$arm_arch

Hi While it might be CPU independent the configure script on linux only pays attention to --enable-fast-bitblt in the cases where it is arm*. So no speed up for anyone else.

It does not mean it might not work but not implemented yet.

fastPathBottomToTop does not do much... It just reverse the line order. https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/f5f0e7d98effd7217dded...

I foresee two cases where it could fail: - the fast operation by itself has a BUG (whatether BottomToTop or not) - some integer operations are carried on a larger integer type, transforming negative pitch into a large positive int

The later is possible because `srcPitch` and `dstPitch` are declared usqInt in `operation_t` https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/f5f0e7d98effd7217dded...

`usqInt` is 64bits on ARM64, so far so good, unfortunately those variables are copied to 32 bits local temps in https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/f5f0e7d98effd7217dded...

I think that it is the mistake, because pointer arithmetic in 64 bits will be performed with 64 bits size_t, and the uint32_t will just move the pointer a large amount forward (2^32-pitch) instead of backward (-pitch).

So I think that declaring the local `srcPitch` and `dstPitch` as `usqInt` instead of `uint32_t` might fix the bug.

I have no ARM64 at hand to play with, so up to you to verify the hypothesis.

Closed #617 via b558efdd677dee45458c6d176b642b2b36f46e28.

Excellent! Very clean fix. Thanks!

It works for me on both Arm64 and Arm32.