WIP FreeBSD/aarch64 support #28171

myfreeweb · Jul 18, 2018

I'm trying to get it to work…

building with libunwind disabled for now (I'm actually working on it separately: libunwind/libunwind#83)
crc/auxval and mcontext related fixes are done
(hmm, is this Linux code correct: // Clear link register (x29) — lr is not x29, it's gp_lr on FreeBSD, IIRC Linux has the register array declared as [31] so it's regs[30]??)
still can't finish the build because of crashes. (using llvm 6.0.1 from system)

sys::Memory::InvalidateInstructionCache segfaults the compiler:

* thread #1, name = 'julia', stop reason = signal SIGSEGV
  * frame #0: 0x0000000043ee3f1c libLLVM-6.0.so
    frame #1: 0x0000000042439120 libLLVM-6.0.so`llvm::sys::Memory::InvalidateInstructionCache(void const*, unsigned long) + 28                                                        
    frame #2: 0x0000000040270838 libjulia.so.0.7`(anonymous namespace)::DualMapAllocator<true>::finalize(void) at cgmemmgr.cpp:513                                                    
    frame #3: 0x0000000040270814 libjulia.so.0.7`(anonymous namespace)::DualMapAllocator<true>::finalize(this=0x0000000044904800) at cgmemmgr.cpp:644                                 
    frame #4: 0x000000004026f968 libjulia.so.0.7`(anonymous namespace)::RTDyldMemoryManagerJL::finalizeMemory(this=0x0000000044898a00, ErrMsg=<unavailable>)::RTDyldMemoryManagerJL::fi
nalizeMemory::char_traits<char>, (anonymous namespace)::RTDyldMemoryManagerJL::finalizeMemory::allocator<char> >*) at cgmemmgr.cpp:869                                                
    frame #5: 0x0000000043414fd0 libLLVM-6.0.so`llvm::RuntimeDyld::finalizeWithMemoryManagerLocking(void) + 84                                                                        
    frame #6: 0x000000004023ac48 libjulia.so.0.7`_ZN4llvm3orc24RTDyldObjectLinkingLayer20ConcreteLinkedObjectINSt3__110shared_ptrINS_11RuntimeDyld13MemoryManagerEEENS4_INS_17JITSymbol
ResolverEEEZNS1_9addObjectENS4_INS_6object12OwningBinaryINSA_10ObjectFileEEEEES9_EUlNS3_15__list_iteratorINS3_10unique_ptrINS0_28RTDyldObjectLinkingLayerBase12LinkedObjectENS3_14defau
lt_deleteISI_EEEEPvEERS5_RKSE_NS3_8functionIFvvEEEE_E8finalizeEv [inlined] _ZZN4llvm3orc24RTDyldObjectLinkingLayer9addObjectENSt3__110shared_ptrINS_6object12OwningBinaryINS4_10ObjectF
ileEEEEENS3_INS_17JITSymbolResolverEEEENKUlNS2_15__list_iteratorINS2_10unique_ptrINS0_28RTDyldObjectLinkingLayerBase12LinkedObjectENS2_14default_deleteISE_EEEEPvEERNS_11RuntimeDyldERK
S8_NS2_8functionIFvvEEEE_clESJ_SL_SN_SQ_(this=<unavailable>, H=llvm::orc::RTDyldObjectLinkingLayerBase::ObjHandleT @ x21, RTDyld=0x000000004a6e2800, ObjToLoad=0x000000004a78edc0) at R
TDyldObjectLinkingLayer.h:274
    frame #7: 0x000000004023abf4 libjulia.so.0.7`_ZN4llvm3orc24RTDyldObjectLinkingLayer20ConcreteLinkedObjectINSt3__110shared_ptrINS_11RuntimeDyld13MemoryManagerEEENS4_INS_17JITSymbol
ResolverEEEZNS1_9addObjectENS4_INS_6object12OwningBinaryINSA_10ObjectFileEEEEES9_EUlNS3_15__list_iteratorINS3_10unique_ptrINS0_28RTDyldObjectLinkingLayerBase12LinkedObjectENS3_14defau
lt_deleteISI_EEEEPvEERS5_RKSE_NS3_8functionIFvvEEEE_E8finalizeEv(this=0x000000004a73cbc0) at RTDyldObjectLinkingLayer.h:144                                                           
    frame #8: 0x0000000040235ecc libjulia.so.0.7`JuliaOJIT::addModule(std::__1::unique_ptr<llvm::Module, JuliaOJIT::addModule::default_delete<llvm> >) [inlined] llvm::orc::RTDyldObjec
tLinkingLayer::emitAndFinalize(std::__1::__list_iterator<llvm::orc::RTDyldObjectLinkingLayer::emitAndFinalize::unique_ptr<llvm::orc::RTDyldObjectLinkingLayerBase::LinkedObject, llvm::
orc::RTDyldObjectLinkingLayer::emitAndFinalize::default_delete<llvm::orc::RTDyldObjectLinkingLayerBase> >, void*>) at RTDyldObjectLinkingLayer.h:343
    frame #9: 0x0000000040235ebc libjulia.so.0.7`JuliaOJIT::addModule(std::__1::unique_ptr<llvm::Module, JuliaOJIT::addModule::default_delete<llvm> >) [inlined] llvm::orc::IRCompileLa
yer<llvm::orc::RTDyldObjectLinkingLayer, JuliaOJIT::CompilerT>::emitAndFinalize(this=<unavailable>) at IRCompileLayer.h:91
    frame #10: 0x0000000040235ebc libjulia.so.0.7`JuliaOJIT::addModule(this=<unavailable>, M=<unavailable>) at jitlayers.cpp:622
    frame #11: 0x000000004023683c libjulia.so.0.7`jl_finalize_function(llvm::StringRef) [inlined] jl_add_to_ee(m=unique_ptr<llvm::Module, std::__1::default_delete<llvm::Module> > @ sc
alar) at jitlayers.cpp:850
    frame #12: 0x0000000040236824 libjulia.so.0.7`jl_finalize_function(F=<unavailable>) at jitlayers.cpp:858
    frame #13: 0x00000000401dea80 libjulia.so.0.7`getAddressForFunction(fname=<unavailable>) at codegen.cpp:1299
    frame #14: 0x00000000401def44 libjulia.so.0.7`::jl_generate_fptr(pli=0x0000ffffffffd8d8, decls=<unavailable>, world=<unavailable>) at codegen.cpp:1410
    frame #15: 0x0000000040168e34 libjulia.so.0.7`jl_fptr_trampoline(m=0x0000000045927110, args=0x0000ffffffffd910, nargs=2) at gf.c:1820
    frame #16: 0x00000000402ce8b0 libjulia.so.0.7`do_call(args=<unavailable>, nargs=2, s=0x0000ffffffffdd30) at interpreter.c:324
    frame #17: 0x00000000402cd464 libjulia.so.0.7`eval_body(stmts=0x000000004595c010, s=0x0000ffffffffdd30, start=<unavailable>, toplevel=1) at interpreter.c:558
    frame #18: 0x00000000402cda7c libjulia.so.0.7`jl_interpret_toplevel_thunk_callback(s=0x0000ffffffffdd30, vargs=<unavailable>) at interpreter.c:792
    frame #19: 0x000000004017fbf4 libjulia.so.0.7`Lenter_interpreter_frame_start_val + 4
    frame #20: 0x00000000402cdacc libjulia.so.0.7`jl_interpret_toplevel_thunk(m=<unavailable>, src=<unavailable>) at interpreter.c:801
    frame #21: 0x00000000401979ac libjulia.so.0.7`jl_toplevel_eval_flex(m=<unavailable>, e=<unavailable>, fast=<unavailable>, expanded=<unavailable>) at toplevel.c:821
    frame #22: 0x0000000040175410 libjulia.so.0.7`jl_parse_eval_all(fname=<unavailable>, content=<unavailable>, contentlen=<unavailable>, inmodule=0x00000000458cc010) at ast.c:855
    frame #23: 0x0000000040198560 libjulia.so.0.7`jl_load(module=0x00000000458cc010, fname="") at toplevel.c:855
    frame #24: 0x0000000040182bfc libjulia.so.0.7`_julia_init(rel=<unavailable>) at init.c:749
    frame #25: 0x0000000040183fe4 libjulia.so.0.7`julia_init__threading(rel=<unavailable>) at task.c:302
    frame #26: 0x00000000000202f8 julia
    frame #27: 0x00000000000200b8 julia`__start(argc=-6792, argv=0x0000ffffffffe570, env=0x0000000000000009, cleanup=<unavailable>) at crt1.c:84

Disabled that, now it builds corecompiler.ji successfully, but building sys.ji crashes:

…
combinatorics.jl           
hashing2.jl             
irrationals.jl            
mathconstants.jl           
Segmentation fault (core dumped)

* thread #1, name = 'julia', stop reason = signal SIGSEGV
  * frame #0: 0x00000000444984e0 libthr.so.3`thr_sighandler(sig=11, info=0x0000000045769be0, _ucp=0x0000000045769c30) at thr_sig.c:165
    frame #1: 0x0000fffffffff000
    frame #2: 0x000000005432d2c8
    frame #3: 0x0000000040168e4c libjulia.so.0.7`jl_fptr_trampoline(m=<unavailable>, args=<unavailable>, nargs=<unavailable>) at gf.c:1821
    frame #4: 0x00000000402bb0a0 libjulia.so.0.7`do_call(args=<unavailable>, nargs=2, s=0x0000ffffffffbcd0) at interpreter.c:324
    frame #5: 0x00000000402b9e9c libjulia.so.0.7`eval_body [inlined] eval_stmt_value(stmt=<unavailable>, s=<unavailable>) at interpreter.c:363
    frame #6: 0x00000000402b9e90 libjulia.so.0.7`eval_body(stmts=0x0000000046debb90, s=0x0000ffffffffbcd0, start=<unavailable>, toplevel=1) at interpreter.c:694
    frame #7: 0x00000000402ba26c libjulia.so.0.7`jl_interpret_toplevel_thunk_callback(s=0x0000ffffffffbcd0, vargs=<unavailable>) at interpreter.c:792
    frame #8: 0x000000004017fbf4 libjulia.so.0.7`Lenter_interpreter_frame_start_val + 4
    frame #9: 0x00000000402ba2bc libjulia.so.0.7`jl_interpret_toplevel_thunk(m=<unavailable>, src=<unavailable>) at interpreter.c:801
    frame #10: 0x00000000401979ac libjulia.so.0.7`jl_toplevel_eval_flex(m=<unavailable>, e=<unavailable>, fast=<unavailable>, expanded=<unavailable>) at toplevel.c:821
    frame #11: 0x000000004019692c libjulia.so.0.7`jl_eval_module_expr(parent_module=0x00000000457e0010, ex=<unavailable>) at toplevel.c:233
    frame #12: 0x0000000040196f08 libjulia.so.0.7`jl_toplevel_eval_flex(m=0x00000000457e0010, e=0x0000000047244cf0, fast=1, expanded=0) at toplevel.c:612
    frame #13: 0x0000000040197814 libjulia.so.0.7`jl_toplevel_eval_flex(m=0x00000000457e0010, e=<unavailable>, fast=1, expanded=<unavailable>) at toplevel.c:769
    frame #14: 0x0000000040175410 libjulia.so.0.7`jl_parse_eval_all(fname=<unavailable>, content=<unavailable>, contentlen=<unavailable>, inmodule=0x00000000457e0010) at ast.c:855   
    frame #15: 0x00000000401985f0 libjulia.so.0.7`jl_load_ [inlined] jl_load(module=0x00000000457e0010, fname="mathconstants.jl") at toplevel.c:855
    frame #16: 0x000000004019859c libjulia.so.0.7`jl_load_(module=0x00000000457e0010, str=<unavailable>) at toplevel.c:862
    frame #17: 0x0000000051a5cbb4
    frame #18: 0x0000000051a5c724
    frame #19: 0x00000000402bb0a0 libjulia.so.0.7`do_call(args=<unavailable>, nargs=2, s=0x0000ffffffffceb0) at interpreter.c:324
    frame #20: 0x00000000402b9e9c libjulia.so.0.7`eval_body [inlined] eval_stmt_value(stmt=<unavailable>, s=<unavailable>) at interpreter.c:363
    frame #21: 0x00000000402b9e90 libjulia.so.0.7`eval_body(stmts=0x0000000046e1c190, s=0x0000ffffffffceb0, start=<unavailable>, toplevel=1) at interpreter.c:694
    frame #22: 0x00000000402ba26c libjulia.so.0.7`jl_interpret_toplevel_thunk_callback(s=0x0000ffffffffceb0, vargs=<unavailable>) at interpreter.c:792
    frame #23: 0x000000004017fbf4 libjulia.so.0.7`Lenter_interpreter_frame_start_val + 4
    frame #24: 0x00000000402ba2bc libjulia.so.0.7`jl_interpret_toplevel_thunk(m=<unavailable>, src=<unavailable>) at interpreter.c:801
    frame #25: 0x00000000401979ac libjulia.so.0.7`jl_toplevel_eval_flex(m=<unavailable>, e=<unavailable>, fast=<unavailable>, expanded=<unavailable>) at toplevel.c:821
    frame #26: 0x000000004019692c libjulia.so.0.7`jl_eval_module_expr(parent_module=0x000000004a61b570, ex=<unavailable>) at toplevel.c:233
    frame #27: 0x0000000040196f08 libjulia.so.0.7`jl_toplevel_eval_flex(m=0x000000004a61b570, e=0x00000000457b3110, fast=1, expanded=1) at toplevel.c:612
    frame #28: 0x0000000040175410 libjulia.so.0.7`jl_parse_eval_all(fname=<unavailable>, content=<unavailable>, contentlen=<unavailable>, inmodule=0x000000004a61b570) at ast.c:855   
    frame #29: 0x0000000040198560 libjulia.so.0.7`jl_load(module=0x000000004a61b570, fname="sysimg.jl") at toplevel.c:855
    frame #30: 0x0000000000020bb8 julia
    frame #31: 0x0000000000020518 julia
    frame #32: 0x0000000000020304 julia
    frame #33: 0x00000000000200b8 julia`__start(argc=1, argv=0x0000ffffffffe738, env=0x000000004472d010, cleanup=<unavailable>) at crt1.c:84
    frame #34: 0x0000000040040018 ld-elf.so.1`.rtld_start at rtld_start.S:41

still can't finish the build because of crashes. (using llvm 6.0.1 from system)

Note that while we allow building with the system's LLVM, it's highly discouraged, since we rely a lot on the local patches we provide for it; I don't think we guarantee (or even check) that using the system's LLVM provides a working build. So you may have better luck letting Julia build its own.

ararslan · Jul 18, 2018

still can't finish the build because of crashes. (using llvm 6.0.1 from system)

Note that while we allow building with the system's LLVM, it's highly discouraged, since we rely a lot on the local patches we provide for it; I don't think we guarantee (or even check) that using the system's LLVM provides a working build. So you may have better luck letting Julia build its own.

Cool! This looks like you are hitting #27174, best to compile with a debug build of LLVM to get better error messages.

vchuravy · Jul 18, 2018

Cool! This looks like you are hitting #27174, best to compile with a debug build of LLVM to get better error messages.

Clear link register (x29)

Yes I got the two names reversed in task.c, it should be [30].

yuyichao · Jul 18, 2018

Clear link register (x29)

Yes I got the two names reversed in task.c, it should be [30].

Disabled that, now it builds corecompiler.ji successfully, but building sys.ji crashes:

This will definitely not work.

sys::Memory::InvalidateInstructionCache segfaults the compiler:

What's the instruction it segfaults on?

yuyichao · Jul 18, 2018

Disabled that, now it builds corecompiler.ji successfully, but building sys.ji crashes:

This will definitely not work.

sys::Memory::InvalidateInstructionCache segfaults the compiler:

What's the instruction it segfaults on?

yuyichao · Jul 18, 2018

yuyichao requested changes Jul 18, 2018

View changes

yuyichao · Jul 18, 2018

src/processor_arm.cpp

-#  include <sys/auxv.h>
-#else
-#  define DYN_GETAUXVAL
+#if defined(__GLIBC_PREREQ)


defined(__GLIBC__) is what we use.

yuyichao · Jul 18, 2018

src/processor_arm.cpp

+#  else
+#    define DYN_GETAUXVAL
+#  endif
+#elif defined(__FreeBSD__)


_OS_FREEBSD_

yuyichao · Jul 18, 2018

Make.inc

+ifneq (,$(findstring aarch64,$(ARCH)))
+ifeq ($(USECLANG),1)
+ifeq ($(MARCH),)
+JCFLAGS += -mcrc


Does clang not support the target attribute? This is still wrong if it doesn't though since IIUC it'll allow all the code to use the crc extention.

It does, but it doesn't recognize +crc in the target.

Yes, it'll allow all code to use it, but I don't think LLVM would ever use CRC automatically. Is there a good way to set flags per file in your makefile?

Does it recognize anything else? e.g. armv8-a+crc.

I mean, I was talking about armv8-a+crc, not bare +crc of course :D

https://bugs.chromium.org/p/chromium/issues/detail?id=554632

Apparently that was "fixed", but I don't know where. Not in regular 6.0.1.

Well, I do see a difference bewteen gcc and clang support of target attribute on arm/aarch64 so sometimes one would work but not the other.

Anyway, just leave it like this with a comment should be OK. Adding flag for a specific file is doable but uglier with little gain and it's not really more correct either.

Another way to fix this would be to use assembler text processing tricks and binary code to generate the assemble as binary directly. Given that there are only very few CPU's that people will run julia on that will not have the crc32 extension I think that's not worth doing...

Yeah, exactly. Are there any non-crc32 cores other than X-Gene 1?

I do have an X-Gene 1 so that's one. I couldn't find a feature set for a35 and the arm page didn't mention crc and I didn't find the manual last time I checked.

Also possibly denver 1, I found no info about it...

Hm, actually — clang is fine with the per function +crc… except there was an extra plus sign in __attribute__((target("+crc"))) — clang adds its own plus and you get ++:

'++crc' is not a recognized feature for this target (ignoring feature)

__attribute__((target("crc"))) seems to work

yuyichao · Jul 18, 2018

src/cgmemmgr.cpp

@@ -506,13 +506,15 @@ class ROAllocator {
    virtual ~ROAllocator() {}
    virtual void finalize()
    {
+#ifndef _CPU_AARCH64_


As mentioned in the comment, this is certainly wrong, if you need this for testing, at least enable it for only freebsd.

yuyichao · Jul 18, 2018

src/crc32c.c

@@ -324,6 +324,9 @@ CRC_TARGET static uint32_t crc32c_armv8(uint32_t crc, const char *buf, size_t le
 }

 // HW feature detection
+#ifndef HWCAP_CRC32


Is this not defined by the auxv header? (That was the whole point....)

No, the header doesn't define any features. https://github.com/freebsd/freebsd/blob/master/sys/sys/auxv.h

Is this defined anywhere then? It'll also be better to condition this on freebsd, since I don't think these values are universal (it does seem that the freebsd value is the same as the linux one in this case)

It appears not: https://github.com/freebsd/freebsd/search?q=hwcap_crc32&unscoped_q=hwcap_crc32

No, there are no HWCAP defines at all.

yuyichao · Jul 18, 2018

src/signals-unix.c

+    ucontext_t *ctx = (ucontext_t*)_ctx;
+    ctx->uc_mcontext.mc_gpregs.gp_sp = rsp;
+    ctx->uc_mcontext.mc_gpregs.gp_x[29] = 0; // Clear link register (x29)
+    ctx->uc_mcontext.mc_gpregs.gp_elr = (uintptr_t)fptr;


That's a strange name for pc........

Indeed.

https://lists.freebsd.org/pipermail/freebsd-arm/2017-February/015611.html

OK, I kind of see where it gets its name from.... It's the address you return to after exception?... But seriously?...... Anyway, that's not important for the PR...

Compiled bundled llvm (debug mode).

First crash (cache invalidation):

* thread #1, name = 'julia', stop reason = signal SIGSEGV
  * frame #0: 0x00000000426e5034 libLLVM-6.0.so`__clear_cache(start=0x0000000048a6ffb0, end=0x0000000048a70124) at clear_cache.c:168                                                                          
    frame #1: 0x0000000041569d08 libLLVM-6.0.so`llvm::sys::Memory::InvalidateInstructionCache(void const*, unsigned long) + 28                                                                                
    frame #2: 0x0000000040252438 libjulia.so.0.7`(anonymous namespace)::DualMapAllocator<true>::finalize() at cgmemmgr.cpp:513                                                                                
    frame #3: 0x0000000040252414 libjulia.so.0.7`(anonymous namespace)::DualMapAllocator<true>::finalize(this=0x0000000048875200) at cgmemmgr.cpp:644                                                         
    frame #4: 0x0000000040251550 libjulia.so.0.7`(anonymous namespace)::RTDyldMemoryManagerJL::finalizeMemory(this=0x0000000042a4fa00, ErrMsg=<unavailable>) at cgmemmgr.cpp:869                              
…

libLLVM-6.0.so`__clear_cache:
    0x426e5014 <+0>:  mrs    x8, CTR_EL0
    0x426e5018 <+4>:  ubfx   w10, w8, #16, #4
    0x426e501c <+8>:  orr    w9, wzr, #0x4
    0x426e5020 <+12>: lsl    w10, w9, w10
    0x426e5024 <+16>: neg    x11, x10
    0x426e5028 <+20>: and    x11, x11, x0
    0x426e502c <+24>: cmp    x11, x1
    0x426e5030 <+28>: b.hs   0x1b0c044                 ; <+48> at clear_cache.c:171
->  0x426e5034 <+32>: dc     cvau, x11
    0x426e5038 <+36>: add    x11, x11, x10
    0x426e503c <+40>: cmp    x11, x1
    0x426e5040 <+44>: b.lo   0x1b0c034                 ; <+32> at clear_cache.c:168
    0x426e5044 <+48>: and    w8, w8, #0xf
    0x426e5048 <+52>: lsl    w8, w9, w8
    0x426e504c <+56>: neg    x9, x8
    0x426e5050 <+60>: and    x9, x9, x0
    0x426e5054 <+64>: cmp    x9, x1
    0x426e5058 <+68>: dsb    ish
    0x426e505c <+72>: b.hs   0x1b0c070                 ; <+92> at clear_cache.c:175
    0x426e5060 <+76>: ic     ivau, x9
    0x426e5064 <+80>: add    x9, x9, x8
    0x426e5068 <+84>: cmp    x9, x1
    0x426e506c <+88>: b.lo   0x1b0c060                 ; <+76> at clear_cache.c:174
    0x426e5070 <+92>: isb
    0x426e5074 <+96>: ret

(void *) start = 0x0000000048a6ffb0
(void *) end = 0x0000000048a70124
(uint64_t) xstart = 1218903984
(uint64_t) xend = 1218904356
(uint64_t) ctr_el0 = 2219081732
(size_t) dcache_line_size = 64
(uint64_t) addr = 1218904064
(size_t) icache_line_size = <variable not available>

https://github.com/llvm-mirror/compiler-rt/blob/f3c53c57134e51a1db5d78478125aeda7d81fa20/lib/builtins/clear_cache.c#L168

The trampoline crash is not in LLVM, so debug LLVM didn't change anything.

myfreeweb · Jul 20, 2018

Compiled bundled llvm (debug mode).

First crash (cache invalidation):

* thread #1, name = 'julia', stop reason = signal SIGSEGV
  * frame #0: 0x00000000426e5034 libLLVM-6.0.so`__clear_cache(start=0x0000000048a6ffb0, end=0x0000000048a70124) at clear_cache.c:168                                                                          
    frame #1: 0x0000000041569d08 libLLVM-6.0.so`llvm::sys::Memory::InvalidateInstructionCache(void const*, unsigned long) + 28                                                                                
    frame #2: 0x0000000040252438 libjulia.so.0.7`(anonymous namespace)::DualMapAllocator<true>::finalize() at cgmemmgr.cpp:513                                                                                
    frame #3: 0x0000000040252414 libjulia.so.0.7`(anonymous namespace)::DualMapAllocator<true>::finalize(this=0x0000000048875200) at cgmemmgr.cpp:644                                                         
    frame #4: 0x0000000040251550 libjulia.so.0.7`(anonymous namespace)::RTDyldMemoryManagerJL::finalizeMemory(this=0x0000000042a4fa00, ErrMsg=<unavailable>) at cgmemmgr.cpp:869                              
…

libLLVM-6.0.so`__clear_cache:
    0x426e5014 <+0>:  mrs    x8, CTR_EL0
    0x426e5018 <+4>:  ubfx   w10, w8, #16, #4
    0x426e501c <+8>:  orr    w9, wzr, #0x4
    0x426e5020 <+12>: lsl    w10, w9, w10
    0x426e5024 <+16>: neg    x11, x10
    0x426e5028 <+20>: and    x11, x11, x0
    0x426e502c <+24>: cmp    x11, x1
    0x426e5030 <+28>: b.hs   0x1b0c044                 ; <+48> at clear_cache.c:171
->  0x426e5034 <+32>: dc     cvau, x11
    0x426e5038 <+36>: add    x11, x11, x10
    0x426e503c <+40>: cmp    x11, x1
    0x426e5040 <+44>: b.lo   0x1b0c034                 ; <+32> at clear_cache.c:168
    0x426e5044 <+48>: and    w8, w8, #0xf
    0x426e5048 <+52>: lsl    w8, w9, w8
    0x426e504c <+56>: neg    x9, x8
    0x426e5050 <+60>: and    x9, x9, x0
    0x426e5054 <+64>: cmp    x9, x1
    0x426e5058 <+68>: dsb    ish
    0x426e505c <+72>: b.hs   0x1b0c070                 ; <+92> at clear_cache.c:175
    0x426e5060 <+76>: ic     ivau, x9
    0x426e5064 <+80>: add    x9, x9, x8
    0x426e5068 <+84>: cmp    x9, x1
    0x426e506c <+88>: b.lo   0x1b0c060                 ; <+76> at clear_cache.c:174
    0x426e5070 <+92>: isb
    0x426e5074 <+96>: ret

(void *) start = 0x0000000048a6ffb0
(void *) end = 0x0000000048a70124
(uint64_t) xstart = 1218903984
(uint64_t) xend = 1218904356
(uint64_t) ctr_el0 = 2219081732
(size_t) dcache_line_size = 64
(uint64_t) addr = 1218904064
(size_t) icache_line_size = <variable not available>

https://github.com/llvm-mirror/compiler-rt/blob/f3c53c57134e51a1db5d78478125aeda7d81fa20/lib/builtins/clear_cache.c#L168

The trampoline crash is not in LLVM, so debug LLVM didn't change anything.

WIP FreeBSD/aarch64 support

Loading status checks…

7e9ecb7

ararslan added freebsd arm labels Jul 18, 2018

ararslan requested review from staticfloat and vchuravy Jul 18, 2018

vchuravy requested a review from yuyichao Jul 18, 2018

JuliaLang/julia

WIP FreeBSD/aarch64 support #28171

myfreeweb commented Jul 18, 2018

ararslan added freebsd arm labels Jul 18, 2018

This comment has been minimized.

ararslan commented Jul 18, 2018

ararslan requested review from staticfloat and vchuravy Jul 18, 2018

vchuravy requested a review from yuyichao Jul 18, 2018

This comment has been minimized.

vchuravy commented Jul 18, 2018

This comment has been minimized.

yuyichao commented Jul 18, 2018

This comment has been minimized.

yuyichao commented Jul 18, 2018

yuyichao requested changes Jul 18, 2018

View changes

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

myfreeweb commented Jul 20, 2018

JuliaLang/julia

Join GitHub today

WIP FreeBSD/aarch64 support #28171

Conversation

myfreeweb commented Jul 18, 2018

ararslan added freebsd arm labels Jul 18, 2018

This comment has been minimized.

ararslan commented Jul 18, 2018

ararslan requested review from staticfloat and vchuravy Jul 18, 2018

vchuravy requested a review from yuyichao Jul 18, 2018

This comment has been minimized.

vchuravy commented Jul 18, 2018

This comment has been minimized.

yuyichao commented Jul 18, 2018

This comment has been minimized.

yuyichao commented Jul 18, 2018

yuyichao requested changes Jul 18, 2018 View changes

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

myfreeweb commented Jul 20, 2018

yuyichao requested changes Jul 18, 2018

View changes