[Vm-dev] Aarch64 number bug

[Bruce O'Neel]

Playing with Git bisect gets us to the commit below as the first bad
one.

I started the git bisect with the two commits below.  The first one
is bad, the second is the good one.

a783502b249c4a4fedc88b6e07837d405feab144 - zero9 - builds, zero error.

9f73148b8da4bc00278b83faa8da6b1c418fa54f - zero10 - builds works

Now this is not 100% guaranteed because one of the commits that git
bisect chose had a build error so I had to mark that one as bad.  But
the commit found does sound possible.

f632ee2888014ee88330ee994e13c9c609b57b5f is the first bad commit

commit f632ee2888014ee88330ee994e13c9c609b57b5f

Author: Eliot Miranda <eliot.miranda at gmail.com>

Date:   Wed Sep 2 10:45:27 2020 -0700

    CogVM source as per VMMaker.oscog-eem.2799/ClosedVMMaker-eem.98

    

    Ha!  I am *STUPID*.

    Integer overflow is not only determined by the upper 64-bits of
a 64x64=>128 bit

    multiply being either all zero or all ones (0 or -1), but by the
upper 64-bits

    being an extension of the most significant bit of the lower 64
bits!!

:040000 040000 ffb8fbcd8ab5e2ca1936429b2daaade62909c178
a5ac89d8b1d4980c5329835cdd3d4a2387b1fac5 M      nsspur64src

:040000 040000 e606dac14ee1db4ac59b0949bb03cd8e657d7aa7
be666051cd1d52d0055e319432b66a0fba61063e M      spur64src

:040000 040000 1dea4faf99821c60e2c2461076bfe8b99d4dea9b
afbef904e8cbc7e4b80e1606420dd6293e12f3e9 M      spurlowcode64src

:040000 040000 f66c681004806d5880af7c0a3115038f4f2f3361
0e8d76bedcf22b6ad7497ea2e3dc44f3c36c2f3a M      spursista64src

On 2021-06-20T21:48:49.000+02:00, Craig Latta
<craig at blackpagedigital.com> wrote:

> Hi Ken--
> 
>       I brought up a development environment on a Raspberry Pi 4.
> 
>  > Unfortunately, my attempt to build a VM simulator on aarch64 fails due
>  > to a divide by zero bug.
>  >
>  > Perhaps because
>  >    16r8000000000000000 printStringHex. ==> '0'
> 
>       update-eem-463.mcm has a postload action which turns on Sista, 
> which recompiles the system, which tries to recompile 
> FloatArrayTest>>testFloatArrayPluginPrimitiveAtPut, which exercises this 
> very bug during scanning, when trying to create the float 1e-127.
> 
>       For now I've rewritten testFloatArrayPluginPrimitiveAtPut and 
> testFloatArrayPluginPrimitiveAt on my system to do nothing. When 
> building GdbARMv8Plugin, there's some other kind of 
> header-include-ordering mayhem, similar to the problem with Linux 
> features.h when building the VM. (At least two levels of it, between 
> bfd.h and the aarch64 simulator's config.h, and config.h and other 
> system headers.) I expect no one has successfully built GdbARMv8Plugin 
> on anything but a M1 macOS machine so far.
> 
> -C
> 
> --
> Craig Latta  ::  research computer scientist
> Black Page Digital  ::  Berkeley, California
> 663137D7940BF5C0AFC :: 1349FB2ADA32C4D5314CE

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20210620/c0198e7d/attachment-0001.html>