Use new arm64 runners for Linux tests

[pguyot]

Continuation of:

• JIT: Add jit target architecture to cache key as jit beams differ #1890

These changes are made under both the "Apache 2.0" and the "GNU Lesser General
Public License 2.1 or later" license terms (dual license).

SPDX-License-Identifier: Apache-2.0 OR LGPL-2.1-or-later

[petermm]

roundfloat:
Expected -3, got: -2
roundfloat:FAILED

and:

floatmath:
CRASH 
======
pid: <0.1.0>

Stacktrace:
[{floatmath,test_pow,0,[{file,"/__w/AtomVM/AtomVM/tests/erlang_tests/floatmath.erl"},{line,161}]},{floatmath,start,0,[{file,"/__w/AtomVM/AtomVM/tests/erlang_tests/floatmath.erl"},{line,47}]}]

cp: #CP<module: 0, label: 92, offset: 183>

x[0]: error
x[1]: {badmatch,0}
x[2]: {2,2,51,1,[{0,102},{0,2667}],error}

Stack 
-----

[]
#CP<module: 0, label: 2, offset: 92>
#CP<module: 0, label: 162, offset: 0>


Mailbox
-------


Monitors
--------


**End Of Crash Report**
Expected 0 but result is not an integer
floatmath:FAILED

[pguyot]

I ran the tests on macOS AArch64 with multipass and latest ubuntu, and they pass.
I have yet to try this on a real Unix AArch64 platform, maybe a Pi Zero 2 I have around.

I suspect something wrong with FP flags, I remember it was initially quite a pain that Fred worked on.

[UncleGrumpy]

On 2 different aarch64 machines, with different Linux distributions both have the same 2 errors when running build/tests/test-erlang:

Unable to open test_op_bs_start_match_asm.beam
Failed load module: test_op_bs_start_match_asm.beam
Warning: module test_op_bs_start_match_asm cannot be resolved.
CRASH 
======
pid: <0.1.0>

Stacktrace:
[{test_op_bs_start_match,test_bs_start_match3_fail_label,0,[{file,"/home/winford/work/AtomVM/tests/erlang_tests/test_op_bs_start_match.erl"},{line,46}]},{test_op_bs_start_match,start,0,[{file,"/home/winford/work/AtomVM/tests/erlang_tests/test_op_bs_start_match.erl"},{line,37}]}]

cp: #CP<module: 0, label: 5, offset: 5>

x[0]: error
x[1]: undef
x[2]: {2,2,71,1,[{0,75},{0,127}],error}

Stack 
-----

#CP<module: 0, label: 5, offset: 5>
#CP<module: 0, label: 30, offset: 0>


Mailbox
-------


Monitors
--------


**End Of Crash Report**
Expected 0 but result is not an integer
test_op_bs_start_match:          FAILED
Unable to open test_op_bs_create_bin_asm.beam
Failed load module: test_op_bs_create_bin_asm.beam
Warning: module test_op_bs_create_bin_asm cannot be resolved.
CRASH 
======
pid: <0.1.0>

Stacktrace:
[{test_op_bs_create_bin,test_bs_create_bin_utf8,0,[{file,"/home/winford/work/AtomVM/tests/erlang_tests/test_op_bs_create_bin.erl"},{line,49}]},{test_op_bs_create_bin,start,0,[{file,"/home/winford/work/AtomVM/tests/erlang_tests/test_op_bs_create_bin.erl"},{line,37}]}]

cp: #CP<module: 0, label: 5, offset: 5>

x[0]: error
x[1]: undef
x[2]: {2,2,70,1,[{0,75},{0,150}],error}

Stack 
-----

[]
#CP<module: 0, label: 5, offset: 5>
#CP<module: 0, label: 102, offset: 0>


Mailbox
-------


Monitors
--------


**End Of Crash Report**
Expected 0 but result is not an integer
test_op_bs_create_bin:           FAILED
Unable to open non_existent_module_12345.beam
Failed load module: non_existent_module_12345.beam

[pguyot]

I wasn't able to compile main without JIT enabled on Pico Zero 2. With JIT, there is a test that crashes, but the two mentioned tests pass.

[petermm]

I (think) I've figured it out.. a rabbit hole! - it's due to valgrind apparently not supporting arm64 fully.. have a superceding PR incoming shortly: petermm@8adaf3e

[pguyot]

I (think) I've figured it out.. a rabbit hole! - it's due to valgrind apparently not supporting arm64 fully.. have a superceding PR incoming shortly: petermm@8adaf3e

I eventually was able to run compile AtomVM with jit disabled on this Pi Zero 2. The four offending tests (roundfloat, floatmath, test_op_bs_start_match, test_op_bs_create_bin) pass. They also pass with valgrind (valgrind/stable,now 1:3.24.0-3 arm64). The two maths tests pass when compiled with OTP27 and when compiled on my laptop with OTP28.

So I'm very confused by this bug...

[petermm]

yes, think arm64 is very diverse, eg. try compiling -O3 -march=native -mcpu=native and valgrind completely fails on the github arm64 runner:

roundfloat:
ARM64 front end: load_store
disInstr(arm64): unhandled instruction 0x9903027F
disInstr(arm64): 1001'1001 0000'0011 0000'0010 0111'1111
==26108== valgrind: Unrecognised instruction at address 0x15da34.
==26108==    at 0x15DA34: globalcontext_new (in /home/runner/work/AtomVM/AtomVM/build/tests/test-erlang)
==26108==    by 0x153FBF: test_module_execution (in /home/runner/work/AtomVM/AtomVM/build/tests/test-erlang)
==26108==    by 0x15424B: test_modules_execution (in /home/runner/work/AtomVM/AtomVM/build/tests/test-erlang)
==26108==    by 0x154517: main (in /home/runner/work/AtomVM/AtomVM/build/tests/test-erlang)
==26108== Your program just tried to execute an instruction that Valgrind
==26108== did not recognise.  There are two possible reasons for this.
==26108== 1. Your program has a bug and erroneously jumped to a non-code
==26108==    location.  If you are running Memcheck and you just saw a
==26108==    warning about a bad jump, it's probably your program's fault.
==26108== 2. The instruction is legitimate but Valgrind doesn't handle it,
==26108==    i.e. it's Valgrind's fault.  If you think this is the case or
==26108==    you are not sure, please let us know and we'll try to fix it.
==26108== Either way, Valgrind will now raise a SIGILL signal which will
==26108== probably kill your program.
==26108== 
==26108== Process terminating with default action of signal 4 (SIGILL): dumping core
==26108==  Illegal opcode at address 0x15DA34
==26108==    at 0x15DA34: globalcontext_new (in /home/runner/work/AtomVM/AtomVM/build/tests/test-erlang)
==26108==    by 0x153FBF: test_module_execution (in /home/runner/work/AtomVM/AtomVM/build/tests/test-erlang)
==26108==    by 0x15424B: test_modules_execution (in /home/runner/work/AtomVM/AtomVM/build/tests/test-erlang)
==26108==    by 0x154517: main (in /home/runner/work/AtomVM/AtomVM/build/tests/test-erlang)
==26108== 
==26108== HEAP SUMMARY:
==26108==     in use at exit: 504 bytes in 3 blocks
==26108==   total heap usage: 3 allocs, 0 frees, 504 bytes allocated
==26108== 
==26108== LEAK SUMMARY:
==26108==    definitely lost: 472 bytes in 1 blocks
==26108==    indirectly lost: 0 bytes in 0 blocks
==26108==      possibly lost: 0 bytes in 0 blocks
==26108==    still reachable: 32 bytes in 2 blocks
==26108==         suppressed: 0 bytes in 0 blocks
==26108== Rerun with --leak-check=full to see details of leaked memory
==26108== 
==26108== For lists of detected and suppressed errors, rerun with: -s
==26108== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

I assume valgrind "fully" supports raspberry pi arm64, but obviously not any arm64 - but it's a rabbit hole for sure..

[petermm]

This looks good, I suggest having a separate step with the ./tests/test-erlang -s prime_smp before the (various) valgrind run..

That way some sanity can be kept and it's obvious if it's valgrind that is influencing the outcome of test-erlang.

But either way is good for me.

[petermm]

btw:
484426 aarch64: 0.5 gets rounded to 0
valgrind 3.23: https://valgrind.org/docs/manual/dist.news.html

we could use valgrind 3.25.1 from snap: sudo snap install valgrind --classic or compile from source..

[petermm]

nitpicks, would be lack of "-O2" and "-DAVM_WARNINGS_ARE_ERRORS=ON", which old arm64 tests had - but you know better than me..