ARM64 Task Force

Manuel M T Chakravarty chak at cse.unsw.edu.au
Thu Aug 14 03:22:03 UTC 2014


That’s awesome — great work!

Manuel

Luke Iannini <lukexipd at gmail.com>:
> Indeed, the float register stuff was a red herring — restoring it caused no problems and all my tests are working great. So yahoo!! We've got ARM64 support.
> 
> I'll tidy up the patches and create a ticket for review and merge.
> 
> Luke
> 
> 
> On Tue, Aug 12, 2014 at 4:47 PM, Luke Iannini <lukexipd at gmail.com> wrote:
> Hi all,
> Yahoo, happy news —  I think I've got it. Studying enough of the non-handwritten ASM that I was stepping through led me to make this change:
> https://github.com/lukexi/ghc/commit/1140e11db07817fcfc12446c74cd5a2bcdf92781
> (I think disabling the floating point registers was just a red herring; I'll confirm that next)
> 
> And I can now call this fib code happily via the FFI:
> fibs :: [Int] 
> fibs = 1:1:zipWith (+) fibs (tail fibs)
> 
> foreign export ccall fib :: Int -> Int
> fib :: Int -> Int
> fib = (fibs !!)
> 
> For posterity, more detail on the crashing case earlier (this is fixed now with proper storage and updating of the frame pointer):
> Calling fib(1) or fib(2) worked, but calling fib(3) triggered the crash.
> This was the backtrace, where you can see the errant 0x0000000100f05110 frame values.
> (lldb) bt
> * thread #1: tid = 0xac6ed, 0x0000000100f05110, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=2, address=0x100f05110)
>     frame #0: 0x0000000100f05110
>     frame #1: 0x0000000100f05110
>   * frame #2: 0x00000001000ffc9c HelloHaskell`-[SPJViewController viewDidLoad](self=0x0000000144e0cf10, _cmd=0x0000000186ae429a) + 76 at SPJViewController.m:22
>     frame #3: 0x00000001862f8b70 UIKit`-[UIViewController loadViewIfRequired] + 692
>     frame #4: 0x00000001862f8880 UIKit`-[UIViewController view] + 32
>     frame #5: 0x00000001862feeb0 UIKit`-[UIWindow addRootViewControllerViewIfPossible] + 72
>     frame #6: 0x00000001862fc6d4 UIKit`-[UIWindow _setHidden:forced:] + 296
>     frame #7: 0x000000018636d2bc UIKit`-[UIWindow makeKeyAndVisible] + 56
>     frame #8: 0x000000018657ff74 UIKit`-[UIApplication _callInitializationDelegatesForMainScene:transitionContext:] + 2804
>     frame #9: 0x00000001865824ec UIKit`-[UIApplication _runWithMainScene:transitionContext:completion:] + 1480
>     frame #10: 0x0000000186580b84 UIKit`-[UIApplication workspaceDidEndTransaction:] + 184
>     frame #11: 0x0000000189d846ac FrontBoardServices`__31-[FBSSerialQueue performAsync:]_block_invoke + 28
>     frame #12: 0x0000000181c7a360 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ + 20
>     frame #13: 0x0000000181c79468 CoreFoundation`__CFRunLoopDoBlocks + 312
>     frame #14: 0x0000000181c77a8c CoreFoundation`__CFRunLoopRun + 1756
>     frame #15: 0x0000000181ba5664 CoreFoundation`CFRunLoopRunSpecific + 396
>     frame #16: 0x0000000186363140 UIKit`-[UIApplication _run] + 552
>     frame #17: 0x000000018635e164 UIKit`UIApplicationMain + 1488
>     frame #18: 0x0000000100100268 HelloHaskell`main(argc=1, argv=0x000000016fd07a58) + 204 at main.m:24
>     frame #19: 0x00000001921eea08 libdyld.dylib`start + 4
> 
> 
> 
> On Tue, Aug 12, 2014 at 11:24 AM, Karel Gardas <karel.gardas at centrum.cz> wrote:
> On 08/12/14 11:03 AM, Luke Iannini wrote:
> It looks like it's jumping somewhere strange; lldb tells me it's to
> 0x100e05110: .long 0x00000000 ; unknown opcode
> 0x100e05114: .long 0x00000000 ; unknown opcode
> 0x100e05118: .long 0x00000000 ; unknown opcode
> 0x100e0511c: .long 0x00000000 ; unknown opcode
> 0x100e05120: .long 0x00000000 ; unknown opcode
> 0x100e05124: .long 0x00000000 ; unknown opcode
> 0x100e05128: .long 0x00000000 ; unknown opcode
> 0x100e0512c: .long 0x00000000 ; unknown opcode
> 
> If I put a breakpoint on StgRun and step by instruction, I seem to make
> it to about:
> https://github.com/lukexi/ghc/blob/e99b7a41e64f3ddb9bb420c0d5583f0e302e321e/rts/StgCRun.c#L770
> (give or take a line)
> 
> strange that it's in the middle of the stp isns block. Anyway, this looks like a cpu exception doesn't it? You will need to find out the reg which holds the "exception reason" value and then look on it in your debugger to find out what's going wrong there.
> 
> Karel
> 
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140814/6a91b665/attachment.html>


More information about the ghc-devs mailing list