Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

arm64 OTP 25-rc2 segfaults during compilation of parsetools on FreeBSD 13.0-RELEASE+ #5817

Closed
dch opened this issue Mar 24, 2022 · 14 comments
Closed
Assignees
Labels
bug Issue is reported as a bug team:VM Assigned to OTP team VM

Comments

@dch
Copy link
Contributor

dch commented Mar 24, 2022

Describe the bug

arm64 OTP 25-rc2 segfaults during compilation of parsetools on FreeBSD 13.0-RELEASE+.

To Reproduce

  • get an arm64 flavoured FreeBSD 13.0-RELEASE or higher, I can help with this if needed
$ tar xzf ... && cd ...
$ sudo pkg install -yr FreeBSD perl5 gmake git-tiny
$ ./configure --without-dynamic-trace --without-javac --without-odbc --with-ssl=/usr --enable-sctp --without-wx-config --prefix=/tmp/jit
$ gmake -j64

...
asmjit/core/cpuinfo.cpp:1117:11: warning: [asmjit] Disabling runtime CPU detection - unsupported OS/CPU combination (Unknown OS with AArch64 CPU) [-W#pragma-messages]
...
 VSN    ../ebin/parsetools.appup
gmake[3]: *** [/tmp/otp/make/aarch64-unknown-freebsd14.0/otp.mk:134: ../ebin/leex.beam] Segmentation fault (core dumped)

Expected behavior

pure jit goodness all the time, from compile to runtime.

Affected versions

OTP 25-rc2.

Additional context

...
if test ! -d /tmp/otp/bootstrap/bin/aarch64-unknown-freebsd14.0 ; then mkdir /tmp/otp/bootstrap/bin/aarch64-unknown-freebsd14.0 ; fi
 MAKE   secondary_bootstrap_build
gmake[1]: Entering directory '/tmp/otp/lib'
gmake[2]: Entering directory '/tmp/otp/lib/parsetools'
=== Entering application parsetools
gmake[3]: Entering directory '/tmp/otp/lib/parsetools/src'
 ERLC   ../ebin/leex.beam
 ERLC   ../ebin/yecc.beam
 ERLC   ../ebin/yeccparser.beam
 ERLC   ../ebin/yeccscan.beam
 VSN    ../ebin/parsetools.app
 VSN    ../ebin/parsetools.appup
gmake[3]: *** [/tmp/otp/make/aarch64-unknown-freebsd14.0/otp.mk:134: ../ebin/leex.beam] Segmentation fault (core dumped)
gmake[3]: *** Waiting for unfinished jobs....
gmake[3]: *** [/tmp/otp/make/aarch64-unknown-freebsd14.0/otp.mk:134: ../ebin/yecc.beam] Segmentation fault (core dumped)
gmake[3]: *** [/tmp/otp/make/aarch64-unknown-freebsd14.0/otp.mk:134: ../ebin/yeccscan.beam] Segmentation fault (core dumped)
gmake[3]: *** [/tmp/otp/make/aarch64-unknown-freebsd14.0/otp.mk:134: ../ebin/yeccparser.beam] Segmentation fault (core dumped)
gmake[3]: Leaving directory '/tmp/otp/lib/parsetools/src'
gmake[2]: *** [/tmp/otp/make/otp_subdir.mk:29: opt] Error 2
gmake[2]: Leaving directory '/tmp/otp/lib/parsetools'
gmake[1]: *** [/tmp/otp/make/otp_subdir.mk:29: opt] Error 2
gmake[1]: Leaving directory '/tmp/otp/lib'
gmake: *** [Makefile:634: secondary_bootstrap_build] Error 2
@dch dch added the bug Issue is reported as a bug label Mar 24, 2022
@jhogberg jhogberg self-assigned this Mar 25, 2022
@jhogberg jhogberg added the team:VM Assigned to OTP team VM label Mar 25, 2022
@jhogberg
Copy link
Contributor

jhogberg commented Mar 25, 2022

Thanks for your report!

It would be nice to know where it crashes, can you try the following?

# Build the system without JIT to dodge the error
$ ./otp_build setup -a --disable-jit
$ make TYPE=debug

# Build the JIT alone
$ ./configure --enable-jit
$ make emulator TYPE=debug

# Start Erlang under GDB, then run `r` and hope it crashes. You
# might need to compile something to provoke the crash.
#
# Once it crashes, run `bt`, `x/8i $pc-16`, and post the result here.
$ cerl -debug -rgdb

@dch
Copy link
Contributor Author

dch commented Mar 25, 2022

well the main thing that stands out to me is the warning:

 CXX    obj/aarch64-unknown-freebsd14.0/debug/jit/asmjit/arm/armformatter.o
asmjit/core/cpuinfo.cpp:1117:11: warning: [asmjit] Disabling runtime CPU detection - unsupported OS/CPU combination (Unknown OS with AArch64 CPU) [-W#pragma-messages]
  #pragma message("[asmjit] Disabling runtime CPU detection - unsupported OS/CPU combination (Unknown OS with AArch64 CPU)")
          ^
1 warning generated.

cerl

sudo ./bin/cerl -debug -rlldb
fish: Job 1, './bin/cerl -debug -rlldb' terminated by signal SIGSEGV (Address boundary error)

I couldn't get cerl to work, but I tried this:

sudo lldb ./bin/aarch64-unknown-freebsd14.0/beam.debug.jit
(lldb) target create "./bin/aarch64-unknown-freebsd14.0/beam.debug.jit"
Current executable set to '/tmp/otp/bin/aarch64-unknown-freebsd14.0/beam.debug.jit' (aarch64).
(lldb) r
Process 11634 launched: '/tmp/otp/bin/aarch64-unknown-freebsd14.0/beam.debug.jit' (aarch64)
Process 11634 stopped
* thread #1, name = 'beam.debug.jit', stop reason = signal SIGSEGV: address access protected (fault address: 0xde600000)
    frame #0: 0x0000000000769f54 beam.debug.jit`__clear_cache(start=0x00000000de600000, end=0x00000000de60294c) at clear_cache.c:119:7
   116      const size_t dcache_line_size = 4 << ((ctr_el0 >> 16) & 15);
   117      for (addr = xstart & ~(dcache_line_size - 1); addr < xend;
   118           addr += dcache_line_size)
-> 119        __asm __volatile("dc cvau, %0" ::"r"(addr));
   120    }
   121    __asm __volatile("dsb ish");
   122
(lldb) bt
* thread #1, name = 'beam.debug.jit', stop reason = signal SIGSEGV: address access protected (fault address: 0xde600000)
  * frame #0: 0x0000000000769f54 beam.debug.jit`__clear_cache(start=0x00000000de600000, end=0x00000000de60294c) at clear_cache.c:119:7
    frame #1: 0x00000000003feb60 beam.debug.jit`BeamAssembler::_codegen(this=0x00000000d4597000, allocator=0x000000008b5f7018, executable_ptr=<unavailable>, writable_ptr=<unavailable>) at beam_jit_common.cpp:128:5
    frame #2: 0x00000000003ea4e8 beam.debug.jit`BeamGlobalAssembler::BeamGlobalAssembler(this=0x00000000d4597000, allocator=0x000000008b5f7018) at beam_asm_global.cpp:71:9
    frame #3: 0x00000000004034dc beam.debug.jit`::beamasm_init() at beam_jit_main.cpp:256:15
    frame #4: 0x000000000049c908 beam.debug.jit`erl_init(ncpu=32, proc_tab_sz=262144, legacy_proc_tab=0, port_tab_sz=65536, port_tab_sz_ignore_files=0, legacy_port_tab=0, sys_proc_outst_req_lim=64, time_correction=1, time_warp_mode=ERTS_NO_TIME_WARP_MODE, node_tab_delete_delay=60, db_spin_count=ERTS_DB_SPNCNT_NORMAL) at erl_init.c:355:5
    frame #5: 0x000000000049b0a8 beam.debug.jit`erl_start(argc=1, argv=0x00000000816fdd30) at erl_init.c:2424:5
    frame #6: 0x00000000003c0828 beam.debug.jit`main(argc=1, argv=0x00000000816fdd30) at erl_main.c:30:5
    frame #7: 0x00000000003c063c beam.debug.jit`__start(argc=1, argv=0x00000000816fdd30, env=0x00000000816fdd40, cleanup=<unavailable>) at crt1_c.c:72:7
    frame #8: 0x00000be7875b60d8 ld-elf.so.1`.rtld_start at rtld_start.S:41
(lldb) x/8i $pc-16
    0x769f44: 0xcb0903ea   neg    x10, x9
    0x769f48: 0x8a00014a   and    x10, x10, x0
    0x769f4c: 0xeb01015f   cmp    x10, x1
    0x769f50: 0x540000a2   b.hs   0x769f64                  ; <+76> at clear_cache.c:121:3
->  0x769f54: 0xd50b7b2a   dc     cvau, x10
    0x769f58: 0x8b09014a   add    x10, x10, x9
    0x769f5c: 0xeb01015f   cmp    x10, x1
    0x769f60: 0x54ffffa3   b.lo   0x769f54                  ; <+60> at clear_cache.c:119:7
(lldb) ^D

is that useful?

I've also asked on asmjit about getting FreeBSD & arm64 added to their CI, this will help in the long term.

@jhogberg
Copy link
Contributor

jhogberg commented Mar 25, 2022

Yes, that's very useful. By the way, you can start the emulator under LLDB with cerl -debug -lldb (no r).

It seems to crash when it clears the instruction cache for the generated code. Just as a sanity check I'd like to see if start[0] and end[-1] are readable:

  * frame #0: 0x0000000000769f54 beam.debug.jit`__clear_cache(start=0x00000000de600000, end=0x00000000de60294c) at clear_cache.c:119:7

The values of start, end, $x0, $x1, $x9, and$x10 would also be nice.

@dch
Copy link
Contributor Author

dch commented Mar 25, 2022

hmm the cerl is still grumpy, not sure what lldb is trying to do here, confused about the script type perhaps?

sudo ./bin/cerl -debug -lldb
(lldb) target create "beam.debug.smp"
Current executable set to 'beam.debug.smp' (aarch64).
(lldb) settings set -- target.run-args  "--" "-root" "/tmp/otp" "-progname" "/tmp/otp/bin/cerl" "-debug" "--" "-home" "/root" "--" "-emu_type" "debug"
(lldb) command source -s 0 '/tmp/.cerllldb.17740'
Executing commands in '/tmp/.cerllldb.17740'.
(lldb) env TERM=dumb
(lldb) command script import /tmp/otp/erts/etc/unix/etp.py
error: module importing failed: lua failed to import '/tmp/otp/erts/etc/unix/etp.py': invalid extension
(lldb)

We just blitzed past my lldb skills so hope this is what you need:

sudo lldb ./bin/aarch64-unknown-freebsd14.0/beam.debug.jit
(lldb) target create "./bin/aarch64-unknown-freebsd14.0/beam.debug.jit"
Current executable set to '/tmp/otp/bin/aarch64-unknown-freebsd14.0/beam.debug.jit' (aarch64).

(lldb) run
Process 40356 launched: '/tmp/otp/bin/aarch64-unknown-freebsd14.0/beam.debug.jit' (aarch64)
Process 40356 stopped
* thread #1, name = 'beam.debug.jit', stop reason = signal SIGSEGV: address access protected (fault address: 0xdee00000)
    frame #0: 0x0000000000769f54 beam.debug.jit`__clear_cache(start=0x00000000dee00000, end=0x00000000dee0294c) at clear_cache.c:119:7
   116      const size_t dcache_line_size = 4 << ((ctr_el0 >> 16) & 15);
   117      for (addr = xstart & ~(dcache_line_size - 1); addr < xend;
   118           addr += dcache_line_size)
-> 119        __asm __volatile("dc cvau, %0" ::"r"(addr));
   120    }
   121    __asm __volatile("dsb ish");
   122

(lldb) bt
* thread #1, name = 'beam.debug.jit', stop reason = signal SIGSEGV: address access protected (fault address: 0xdee00000)
  * frame #0: 0x0000000000769f54 beam.debug.jit`__clear_cache(start=0x00000000dee00000, end=0x00000000dee0294c) at clear_cache.c:119:7
    frame #1: 0x00000000003feb60 beam.debug.jit`BeamAssembler::_codegen(this=0x00000000d4b0e000, allocator=0x000000008b16c018, executable_ptr=<unavailable>, writable_ptr=<unavailable>) at beam_jit_common.cpp:128:5
    frame #2: 0x00000000003ea4e8 beam.debug.jit`BeamGlobalAssembler::BeamGlobalAssembler(this=0x00000000d4b0e000, allocator=0x000000008b16c018) at beam_asm_global.cpp:71:9
    frame #3: 0x00000000004034dc beam.debug.jit`::beamasm_init() at beam_jit_main.cpp:256:15
    frame #4: 0x000000000049c908 beam.debug.jit`erl_init(ncpu=32, proc_tab_sz=262144, legacy_proc_tab=0, port_tab_sz=65536, port_tab_sz_ignore_files=0, legacy_port_tab=0, sys_proc_outst_req_lim=64, time_correction=1, time_warp_mode=ERTS_NO_TIME_WARP_MODE, node_tab_delete_delay=60, db_spin_count=ERTS_DB_SPNCNT_NORMAL) at erl_init.c:355:5
    frame #5: 0x000000000049b0a8 beam.debug.jit`erl_start(argc=1, argv=0x000000008144b690) at erl_init.c:2424:5
    frame #6: 0x00000000003c0828 beam.debug.jit`main(argc=1, argv=0x000000008144b690) at erl_main.c:30:5
    frame #7: 0x00000000003c063c beam.debug.jit`__start(argc=1, argv=0x000000008144b690, env=0x000000008144b6a0, cleanup=<unavailable>) at crt1_c.c:72:7
    frame #8: 0x0000236d2a2f60d8 ld-elf.so.1`.rtld_start at rtld_start.S:41

(lldb) x/8i $pc-16
    0x769f44: 0xcb0903ea   neg    x10, x9
    0x769f48: 0x8a00014a   and    x10, x10, x0
    0x769f4c: 0xeb01015f   cmp    x10, x1
    0x769f50: 0x540000a2   b.hs   0x769f64                  ; <+76> at clear_cache.c:121:3
->  0x769f54: 0xd50b7b2a   dc     cvau, x10
    0x769f58: 0x8b09014a   add    x10, x10, x9
    0x769f5c: 0xeb01015f   cmp    x10, x1
    0x769f60: 0x54ffffa3   b.lo   0x769f54                  ; <+60> at clear_cache.c:119:7

(lldb) x/8i start
    0xdee00000: 0xaa1f03e2   mov    x2, xzr
    0xdee00004: 0xaa1903e3   mov    x3, x25
    0xdee00008: 0xaa1a03e4   mov    x4, x26
    0xdee0000c: 0xaa0403e8   mov    x8, x4
    0xdee00010: 0x91020269   add    x9, x19, #0x80            ; =0x80
    0xdee00014: 0xf100ed1f   cmp    x8, #0x3b                 ; =0x3b
    0xdee00018: 0x54000240   b.eq   0xdee00060
    0xdee0001c: 0x37080148   tbnz   w8, #0x1, 0xdee00044

(lldb) x/8i end
    0xdee0294c: 0x00000000   udf    #0x0
    0xdee02950: 0x00000000   udf    #0x0
    0xdee02954: 0x00000000   udf    #0x0
    0xdee02958: 0x00000000   udf    #0x0
    0xdee0295c: 0x00000000   udf    #0x0
    0xdee02960: 0x00000000   udf    #0x0
    0xdee02964: 0x00000000   udf    #0x0
    0xdee02968: 0x00000000   udf    #0x0

(lldb) x/8i $x0
    0xdee00000: 0xaa1f03e2   mov    x2, xzr
    0xdee00004: 0xaa1903e3   mov    x3, x25
    0xdee00008: 0xaa1a03e4   mov    x4, x26
    0xdee0000c: 0xaa0403e8   mov    x8, x4
    0xdee00010: 0x91020269   add    x9, x19, #0x80            ; =0x80
    0xdee00014: 0xf100ed1f   cmp    x8, #0x3b                 ; =0x3b
    0xdee00018: 0x54000240   b.eq   0xdee00060
    0xdee0001c: 0x37080148   tbnz   w8, #0x1, 0xdee00044

(lldb) x/8i $x1
    0xdee0294c: 0x00000000   udf    #0x0
    0xdee02950: 0x00000000   udf    #0x0
    0xdee02954: 0x00000000   udf    #0x0
    0xdee02958: 0x00000000   udf    #0x0
    0xdee0295c: 0x00000000   udf    #0x0
    0xdee02960: 0x00000000   udf    #0x0
    0xdee02964: 0x00000000   udf    #0x0
    0xdee02968: 0x00000000   udf    #0x0

(lldb) x/8i $x9
error: memory read failed for 0x0

(lldb) x/8i $x10
    0xdee00000: 0xaa1f03e2   mov    x2, xzr
    0xdee00004: 0xaa1903e3   mov    x3, x25
    0xdee00008: 0xaa1a03e4   mov    x4, x26
    0xdee0000c: 0xaa0403e8   mov    x8, x4
    0xdee00010: 0x91020269   add    x9, x19, #0x80            ; =0x80
    0xdee00014: 0xf100ed1f   cmp    x8, #0x3b                 ; =0x3b
    0xdee00018: 0x54000240   b.eq   0xdee00060
    0xdee0001c: 0x37080148   tbnz   w8, #0x1, 0xdee00044
(lldb)

@jhogberg
Copy link
Contributor

jhogberg commented Mar 25, 2022

That's weird. FreeBSD seems to set SCTLR_EL1.UCI so we should be allowed to use dc cvau in user-space as long as we have read access, which we obviously do.

What processor are you using?

@dch
Copy link
Contributor Author

dch commented Mar 25, 2022

I have a few here:

  • Ampere eMAG <- tests done on this
  • Ampere Altra Max <- I will try on this

@dch
Copy link
Contributor Author

dch commented Mar 26, 2022

for my reference, I set the following sysctls while doing this. Same results on both CPUs.

$ sysctl kern.elf64
kern.elf64.allow_wx: 1
kern.elf64.sigfastblock: 0
kern.elf64.aslr.stack: 0
kern.elf64.aslr.honor_sbrk: 0
kern.elf64.aslr.pie_enable: 1
kern.elf64.aslr.enable: 0
kern.elf64.pie_base: 1048576
kern.elf64.nxstack: 0
kern.elf64.fallback_brand: -1

@dch
Copy link
Contributor Author

dch commented Mar 26, 2022

Some background reading for those who are as confused by this as I am.
See a quick reference guide to official arm64 instruction set for
the hefty stuff.

  • JIT segfaults because FreeBSD kernel denies non-privileged access
    for the dc cvau instruction
  • looking up the quick reference shows us this is a cacheline flush
    request
  • elsewhere on Linux, some arm64 errata notes are referred to, which
    I am too uninformed to read easily just yet, while this is armv8
    still, its not the same CPU as we are using

arm64trap userspace "dc cvau" cache operation on errata-affected core

  • this presumably succeeds on Linux arm64 so this is probably not OTP
  • andrew@ gives a small sample of how this would be done normally,
    and notes that it requires PROT_WRITE as well as PROT_READ
#include <sys/mman.h>
#include <assert.h>
#include <stdlib.h>

int
main(int argc, char* argv[])
{
        char *mem;

        mem = mmap(NULL, 64*1024, PROT_READ | PROT_WRITE, MAP_ANON, -1, 0);
        assert(mem != MAP_FAILED);

        __asm __volatile("dc cvau, %0" :: "r"(mem));

        return (0);
}

Andy notes that if a load occurs before dc then this works, even
without PROT_WRITE, and throws a patch
over the wall, without prejudice...

@dch
Copy link
Contributor Author

dch commented Mar 26, 2022

building 14.0-CURRENT with ae9221b8 certainly finished compiling erts without issue, so I assume that's sufficient.

Erlang/OTP 25 [RELEASE CANDIDATE 2] [erts-13.0] [source] [64-bit] [smp:32:32] [ds:32:32:10] [async-threads:1] [jit] [sharing-preserving]

Eshell V13.0  (abort with ^G)
1> erlang:system_info(emu_flavor).
jit
2> os:type().
{unix,freebsd}
3> os:version().
{14,0,0}

I will keep this open until I get a definitive patch into FreeBSD src.

@jhogberg thanks for the debugging expertise! Is there any suitable
test validation I can run here?

@dch
Copy link
Contributor Author

dch commented Mar 26, 2022

reported upstream in FreeBSD

@jhogberg
Copy link
Contributor

jhogberg commented Mar 28, 2022

@jhogberg thanks for the debugging expertise! Is there any suitable test validation I can run here?

Nothing that will catch this issue in specific, it's pretty well-isolated. Otherwise I think the ordinary test suites will do. :)

https://github.com/erlang/otp/blob/master/HOWTO/TESTING.md

for my reference, I set the following sysctls while doing this. Same results on both CPUs.

$ sysctl kern.elf64
kern.elf64.allow_wx: 1
kern.elf64.sigfastblock: 0
kern.elf64.aslr.stack: 0
kern.elf64.aslr.honor_sbrk: 0
kern.elf64.aslr.pie_enable: 1
kern.elf64.aslr.enable: 0
kern.elf64.pie_base: 1048576
kern.elf64.nxstack: 0
kern.elf64.fallback_brand: -1

As an aside, we don't need kern.elf64.allow_wx: the code is mapped twice with one mapping that's writable and another mapping that's executable.

@dch
Copy link
Contributor Author

dch commented Mar 31, 2022

Using https://cgit.freebsd.org/src/commit/?id=029c1c4828aab451ba262cd4e2e1d9362cf18b76 &
https://github.com/fhunleth/beam_benchmarks + Elixir 13.3 we see a whopping 2x improvement in estones, on hw.model: APM eMAG 8180 r3p2. Now running benchmarks in a tight loop is clearly the best case scenario for optimisation, but still that's awesome. Thanks @garazdawi, @jhogberg & @bjorng !

wrt test suite, I see some failures, but nothing that looks relevant for JIT. Let me know if you want the ct logs, they're large.

OTP24 pre-JIT

**** Total time 4.268034 seconds ****
**** ESTONES = 225109 ****

    Title                            Millis        Estone       %    Loops

{'ESTONES',225109}
list manipulation                    87              17487        7     6400
small messages                       1092            2839         10    1515
medium messages                      1122            5413         14    1527
huge messages                        93              5322         4     52
pattern matching                     17              45534        5     1046
traverse                             60              8289         4     2834
Port i/o                             506             8824         12    4800
Work with large dataset              41              6751         3     1193
Work with large local dataset        39              7112         3     1174
Alloc and dealloc                    12              10268        2     3710
Bif dispatch                         45              44031        8     5623
Binary handling                      148             3352         4     581
ets datadictionary                   158             7042         6     342
Generic server (with timeout)        718             3496         9     7977
Small Integer arithmetics            37              7619         3     4157
Float arithmetics                    13              2324         1     5526
Function calls                       31              24980        5     882
Timers                               45              2733         2     2312
Links                                3               11693        1     30
{:comment, 'UNKNOWN MHz, 225109 ESTONES'}

OTP25 + JIT

**** Total time 3.735836 seconds ****
**** ESTONES = 547319 ****

    Title                            Millis        Estone       %    Loops

{'ESTONES',547319}
list manipulation                    30              50339        7     6400
small messages                       1048            2958         10    1515
medium messages                      1072            5665         14    1527
huge messages                        93              5355         4     52
pattern matching                     4               203412       5     1046
traverse                             26              19144        4     2834
Port i/o                             352             12666        12    4800
Work with large dataset              17              16885        3     1193
Work with large local dataset        15              18706        3     1174
Alloc and dealloc                    4               29039        2     3710
Bif dispatch                         48              41310        8     5623
Binary handling                      150             3300         4     581
ets datadictionary                   142             7881         6     342
Generic server (with timeout)        663             3784         9     7977
Small Integer arithmetics            12              23618        3     4157
Float arithmetics                    6               5361         1     5526
Function calls                       10              80527        5     882
Timers                               42              2937         2     2312
Links                                2               14432        1     30
{:comment, 'UNKNOWN MHz, 547319 ESTONES'}

@dch dch closed this as completed Mar 31, 2022
@jhogberg
Copy link
Contributor

Using https://cgit.freebsd.org/src/commit/?id=029c1c4828aab451ba262cd4e2e1d9362cf18b76 &
https://github.com/fhunleth/beam_benchmarks + Elixir 13.3 we see a whopping 2x improvement in estones, on hw.model: APM eMAG 8180 r3p2. Now running benchmarks in a tight loop is clearly the best case scenario for optimisation, but still that's awesome.

Sweet :)

Thanks @garazdawi and @jhogberg!

I'd be amiss not to mention @bjorng, he did at least as much work on the ARM JIT as I did. :)

wrt test suite, I see some failures, but nothing that looks relevant for JIT. Let me know if you want the ct logs, they're large.

Sure, we don't have all that many ARM variants to test on so it would be nice to see the logs, or at least know which cases failed.

@dch
Copy link
Contributor Author

dch commented Mar 31, 2022

Praise duly amended! I'll send test output privately.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Issue is reported as a bug team:VM Assigned to OTP team VM
Projects
None yet
Development

No branches or pull requests

2 participants